OT: Lenguaje en que se desarrollan utilitarios

Tu frase estaría más completa si dijeras "hablando de aplicaciones de
escritorio orientadas
al trabajo con bases de datos". Los juegos también son aplicaciones de
escritorio, para los
que FoxPro no es lo más indicado.

Por supuesto. Si leíste mi mensaje completo verás que lo aclaro más
adelante:
"C# esta a un nivel menos en cuanto a facilidades para sistemas de gestion y
manejo de data.
Ahora bien, para otro tipo de aplicaciones, claro que C# lo supera
bastante."

Yo creo que la diferencia principal entre ellos es que C# es (o intenta
ser, en qué medida
lo logra o no ya puede ser tema de discusión) un lenguaje de propósito
general;

De acuerdo, pero especializar al menos un namespace para propósitos
particulares no estaría nada mal. Muy al contrario, lo enriquecería mucho
más.

Respecto a C++.NET, es muy distinto de C#? Puede una pensar en desarrollar
un sistema de Bases de Datos con C++.NET?


"RFOG" wrote in message
news:

En mi experiencia laboral como creador de aplicativos de sistema, el C# es
un juguete para ese tipo de aplicaciones, el C++/CLI apenas llega (más que
nada por el interop, que es más fácil), y desde luego en equipos embedded
pequeños es muy pero que muy lento. Y olvidémonos de otras máquinas más
exóticas, como microondas, lavadoras, impresoras y satélites.

De forma profesional llevo hechas 4 aplicaciones de sistema en .NET, una
en C# para una placa ejecutando Windows CE 5.0 en un ARM 9 a 200 Mhz y
cumple justito, aparte de que le faltan cosas que los de sistemas usamos a
menudo: arrays de punteros, máquinas de estados, tiempo real estricto o
casi...

Tres de ellas más en PC y con C++/CLI (que no deja de ser .net), dos son
aplicaciones internas a donde trabajo que procesan y transforman gráficos,
y la verdad que en este caso la rapidez de desarrollo compensa la caída de
rendimiento, que a veces no es tanta.

Y la última la estoy terminando, también en C++/CLI, y esta sí que va a
ser la prueba definitiva del .NET, es un aplicativo pesado con muchos
gráficos, trabaja con sockets, hilos, dispositivos exóticos y la verdad es
que el desarrollo está siendo casi una delicia salvo un par de bugs
(aparte de los míos, claro :-P) y la enorme lentitud del IDE...

Pero siempre hay que tener en cuenta una cosa: bugs, las herramientas
actuales de MS están plagadísimas de bugs de todo tipo, aunque parece ser
que el C# es el que menos tiene.

Personalmente, y no deja de ser una mera opinión, pese a todas las lacras
y problemas, siempre que puedo, elijo .NET por la facilidad de desarrollo,
pero no siempre está disponible, y lo cierto es que sería una gran idea si
quitaran de enmedio la máquina virtual y todo fuera a código nativo (como
Delphi y C++ Builder), e hicieran que trabajar con el IDE fuera tan
robusto como el del Delphi, porque con el Visual Studio, a poco que metas
mano, te cargas el diseñador de fichas, y en Delphi (y C++ Builder, sigh,
DEP), hay que tener un par bien puesto para que el diseñador se caiga.

Y sigue siendo mi opinión, el .NET no dejará de ser lo que es hasta que o
quiten la VM y sea algo nativo o la oculten tanto que apenas sea
detectable. Porque el tema de la portabilidad es una falacia como un
castillo. Una aplicación .NET es tan portable como lo es un EXE nativo
hecho en C++ de toda la vida... Una aplicación MFC se ejecutará en los
mismos lugares que una .NET, y en el tema embedded es lo mismo, si
preparas una aplicación .NET para embebido, también la tienes que preparar
en MFC.

Pues eso.

On Tue, 02 Jan 2007 14:24:18 +0100, Ana Zuluaga
wrote:

C# lleva ya como 5 años no? Ya deberia estarse usando mas ;)

Sobre Delphi yo no creo que haya muchas aplicaciones de esas que
pregunta el
companero.

De C++ ciertamente creo que es el que mas se usa para eso. Uno puede
verlo
usando reshacker al EXE para ver las librerias que usa.

"Pablo Iglesias" wrote in
message
news:

Hombre... C# es aún muy "joven" como para que pueda tener una base de
aplicaciones instaladas que pueda llegar a compararse, ni siquiera
remotamente, a lenguajes como Delphi, Java o muchísimo menos C++ o VB.

Piensa que por ejemplo en el caso de C++ estamos hablando de un lenguaje
que
tiene más de 20 años, y no se le han hecho cambios sustanciales como a
Pascal
o Basic...

Saludos

"Alhambra-Eidos" wrote:

Y C# en qué estado queda ?

http://www.alhambra-eidos.com/web2005/index.html


"Pablo Iglesias" wrote:

> Hola Carlos, feliz año :)
>
> El lenguaje en el que estan hechas la mayoría de las aplicaciones que
> usamos
> a diario, es C++. Seguido de cerca por Visual Basic, Java y quizá
> después
> Delphi (Object Pascal). Para muchas de estas aplicaciones, realmente,
> se
> utilizan varios lenguajes (por ejemplo, Visual Basic o Delphi para
> crear la
> interfaz de usuario y C++ para crear DLL's que el programa pueda
> necesitar).
>
> Saludos
>
>
> "Carlos" wrote:
>
> > Hola,
> > tengo la curiosidad de saber cual es el lenguaje que normalmente se
> > usa para
> > programar los softwares utilitarios que uno usa a diario, que
> > adquiere por
> > internet y similares.
> >
> > Gracias
> >
> >
> >

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
> Ningún experimento puede reproducirse.

El C# es un C++ simplificado. Es bastante más potente que el C#,
principalmente permite controlar con más detalle qué estas haciendo (qué
son referencias y qué variables, destrucción determinista) y el interop es
directo. Incluyes "windows.h" y haces las llamadas pertinentes a código
nativo (los tipos básicos se convierten solos). Aparte de que genera
código algo mejor (más que nada porque compila en tres etapas, en lugar
del C#, que si no me equivoco lo hace en dos) y porque la idiosincrasia
del C++ no está presente en el C#. El C++/CLI es mucho más relajado ante
la mezcla de tipos (de manera que tienes que saber qué estás haciendo, si
no puedes armar una gorda), permite punteros a código nativo y compila
todo el código existente sin problemas.

Pero tiene una contrapartida, y es que es un lenguaje mucho más críptico y
difícil. Por ejemplo, en C# un array se declara y define así:

public int[] matriz=new int(10);

En C++/CLI es algo así:

array<int>^matriz=gcnew array<int>(10);

Pero desde luego, una vez acostumbrado a él, todos los demás lenguajes te
parecen juguetes.

Y para bases de datos no creo que sea una buena recomendación, hay muchos
menos asistentes, el IDE es bastante más lento (realmente MUCHO más lento)
y más buggy que bajo C#. EL C++/CLI es bueno para aplicaciones de sistemas
y de escritorio de bajo nivel. Por ejemplo, hoy he escrito algo como esto:

private: System::Void button1_Click(System::Object^, System::EventArgs^) {
::ExitWindowsEx(EWX_REBOOT|EWX_FORCEIFHUNG,0);
}

Eso en C# es mucho más laborioso. Tienes que importar la dll user32.dll,
compatibilizar los tipos y luego llamar a tu envoltorio. Sin embargo en
C++/CLI es directo: estoy haciendo una llamada a una función nativa desde
un evento CLI.

Cada cosa tiene su nicho.

On Wed, 03 Jan 2007 20:36:42 +0100, Ana Zuluaga
wrote:

Respecto a C++.NET, es muy distinto de C#? Puede una pensar en
desarrollar
un sistema de Bases de Datos con C++.NET?


"RFOG" wrote in message
news:

En mi experiencia laboral como creador de aplicativos de sistema, el C#
es
un juguete para ese tipo de aplicaciones, el C++/CLI apenas llega (más
que
nada por el interop, que es más fácil), y desde luego en equipos
embedded
pequeños es muy pero que muy lento. Y olvidémonos de otras máquinas más
exóticas, como microondas, lavadoras, impresoras y satélites.

De forma profesional llevo hechas 4 aplicaciones de sistema en .NET, una
en C# para una placa ejecutando Windows CE 5.0 en un ARM 9 a 200 Mhz y
cumple justito, aparte de que le faltan cosas que los de sistemas
usamos a
menudo: arrays de punteros, máquinas de estados, tiempo real estricto o
casi...

Tres de ellas más en PC y con C++/CLI (que no deja de ser .net), dos son
aplicaciones internas a donde trabajo que procesan y transforman
gráficos,
y la verdad que en este caso la rapidez de desarrollo compensa la caída
de
rendimiento, que a veces no es tanta.

Y la última la estoy terminando, también en C++/CLI, y esta sí que va a
ser la prueba definitiva del .NET, es un aplicativo pesado con muchos
gráficos, trabaja con sockets, hilos, dispositivos exóticos y la verdad
es
que el desarrollo está siendo casi una delicia salvo un par de bugs
(aparte de los míos, claro :-P) y la enorme lentitud del IDE...

Pero siempre hay que tener en cuenta una cosa: bugs, las herramientas
actuales de MS están plagadísimas de bugs de todo tipo, aunque parece
ser
que el C# es el que menos tiene.

Personalmente, y no deja de ser una mera opinión, pese a todas las
lacras
y problemas, siempre que puedo, elijo .NET por la facilidad de
desarrollo,
pero no siempre está disponible, y lo cierto es que sería una gran idea
si
quitaran de enmedio la máquina virtual y todo fuera a código nativo
(como
Delphi y C++ Builder), e hicieran que trabajar con el IDE fuera tan
robusto como el del Delphi, porque con el Visual Studio, a poco que
metas
mano, te cargas el diseñador de fichas, y en Delphi (y C++ Builder,
sigh,
DEP), hay que tener un par bien puesto para que el diseñador se caiga.

Y sigue siendo mi opinión, el .NET no dejará de ser lo que es hasta que
o
quiten la VM y sea algo nativo o la oculten tanto que apenas sea
detectable. Porque el tema de la portabilidad es una falacia como un
castillo. Una aplicación .NET es tan portable como lo es un EXE nativo
hecho en C++ de toda la vida... Una aplicación MFC se ejecutará en los
mismos lugares que una .NET, y en el tema embedded es lo mismo, si
preparas una aplicación .NET para embebido, también la tienes que
preparar
en MFC.

Pues eso.

On Tue, 02 Jan 2007 14:24:18 +0100, Ana Zuluaga

wrote:

C# lleva ya como 5 años no? Ya deberia estarse usando mas ;)

Sobre Delphi yo no creo que haya muchas aplicaciones de esas que
pregunta el
companero.

De C++ ciertamente creo que es el que mas se usa para eso. Uno puede
verlo
usando reshacker al EXE para ver las librerias que usa.

"Pablo Iglesias" wrote in
message
news:

Hombre... C# es aún muy "joven" como para que pueda tener una base de
aplicaciones instaladas que pueda llegar a compararse, ni siquiera
remotamente, a lenguajes como Delphi, Java o muchísimo menos C++ o VB.

Piensa que por ejemplo en el caso de C++ estamos hablando de un
lenguaje
que
tiene más de 20 años, y no se le han hecho cambios sustanciales como a
Pascal
o Basic...

Saludos

"Alhambra-Eidos" wrote:

Y C# en qué estado queda ?

http://www.alhambra-eidos.com/web2005/index.html


"Pablo Iglesias" wrote:

> Hola Carlos, feliz año :)
>
> El lenguaje en el que estan hechas la mayoría de las aplicaciones
que
> usamos
> a diario, es C++. Seguido de cerca por Visual Basic, Java y quizá
> después
> Delphi (Object Pascal). Para muchas de estas aplicaciones,
realmente,
> se
> utilizan varios lenguajes (por ejemplo, Visual Basic o Delphi para
> crear la
> interfaz de usuario y C++ para crear DLL's que el programa pueda
> necesitar).
>
> Saludos
>
>
> "Carlos" wrote:
>
> > Hola,
> > tengo la curiosidad de saber cual es el lenguaje que normalmente
se
> > usa para
> > programar los softwares utilitarios que uno usa a diario, que
> > adquiere por
> > internet y similares.
> >
> > Gracias
> >
> >
> >

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
>> Ningún experimento puede reproducirse.

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
La tragedia de la edad no es ser viejo, sino que se sea joven y la gente
no lo vea.

Muchas gracias por la excelente explicación y éxitos en tus trabajos.

Ana


"RFOG" wrote in message
news:

El C# es un C++ simplificado. Es bastante más potente que el C#,
principalmente permite controlar con más detalle qué estas haciendo (qué
son referencias y qué variables, destrucción determinista) y el interop es
directo. Incluyes "windows.h" y haces las llamadas pertinentes a código
nativo (los tipos básicos se convierten solos). Aparte de que genera
código algo mejor (más que nada porque compila en tres etapas, en lugar
del C#, que si no me equivoco lo hace en dos) y porque la idiosincrasia
del C++ no está presente en el C#. El C++/CLI es mucho más relajado ante
la mezcla de tipos (de manera que tienes que saber qué estás haciendo, si
no puedes armar una gorda), permite punteros a código nativo y compila
todo el código existente sin problemas.

Pero tiene una contrapartida, y es que es un lenguaje mucho más críptico y
difícil. Por ejemplo, en C# un array se declara y define así:

public int[] matriz=new int(10);

En C++/CLI es algo así:

array<int>^matriz=gcnew array<int>(10);

Pero desde luego, una vez acostumbrado a él, todos los demás lenguajes te
parecen juguetes.

Y para bases de datos no creo que sea una buena recomendación, hay muchos
menos asistentes, el IDE es bastante más lento (realmente MUCHO más lento)
y más buggy que bajo C#. EL C++/CLI es bueno para aplicaciones de sistemas
y de escritorio de bajo nivel. Por ejemplo, hoy he escrito algo como esto:

private: System::Void button1_Click(System::Object^, System::EventArgs^) {
::ExitWindowsEx(EWX_REBOOT|EWX_FORCEIFHUNG,0);
}

Eso en C# es mucho más laborioso. Tienes que importar la dll user32.dll,
compatibilizar los tipos y luego llamar a tu envoltorio. Sin embargo en
C++/CLI es directo: estoy haciendo una llamada a una función nativa desde
un evento CLI.

Cada cosa tiene su nicho.

On Wed, 03 Jan 2007 20:36:42 +0100, Ana Zuluaga
wrote:

Respecto a C++.NET, es muy distinto de C#? Puede una pensar en
desarrollar
un sistema de Bases de Datos con C++.NET?


"RFOG" wrote in message
news:

En mi experiencia laboral como creador de aplicativos de sistema, el C#
es
un juguete para ese tipo de aplicaciones, el C++/CLI apenas llega (más
que
nada por el interop, que es más fácil), y desde luego en equipos
embedded
pequeños es muy pero que muy lento. Y olvidémonos de otras máquinas más
exóticas, como microondas, lavadoras, impresoras y satélites.

De forma profesional llevo hechas 4 aplicaciones de sistema en .NET, una
en C# para una placa ejecutando Windows CE 5.0 en un ARM 9 a 200 Mhz y
cumple justito, aparte de que le faltan cosas que los de sistemas
usamos a
menudo: arrays de punteros, máquinas de estados, tiempo real estricto o
casi...

Tres de ellas más en PC y con C++/CLI (que no deja de ser .net), dos son
aplicaciones internas a donde trabajo que procesan y transforman
gráficos,
y la verdad que en este caso la rapidez de desarrollo compensa la caída
de
rendimiento, que a veces no es tanta.

Y la última la estoy terminando, también en C++/CLI, y esta sí que va a
ser la prueba definitiva del .NET, es un aplicativo pesado con muchos
gráficos, trabaja con sockets, hilos, dispositivos exóticos y la verdad
es
que el desarrollo está siendo casi una delicia salvo un par de bugs
(aparte de los míos, claro :-P) y la enorme lentitud del IDE...

Pero siempre hay que tener en cuenta una cosa: bugs, las herramientas
actuales de MS están plagadísimas de bugs de todo tipo, aunque parece
ser
que el C# es el que menos tiene.

Personalmente, y no deja de ser una mera opinión, pese a todas las
lacras
y problemas, siempre que puedo, elijo .NET por la facilidad de
desarrollo,
pero no siempre está disponible, y lo cierto es que sería una gran idea
si
quitaran de enmedio la máquina virtual y todo fuera a código nativo
(como
Delphi y C++ Builder), e hicieran que trabajar con el IDE fuera tan
robusto como el del Delphi, porque con el Visual Studio, a poco que
metas
mano, te cargas el diseñador de fichas, y en Delphi (y C++ Builder,
sigh,
DEP), hay que tener un par bien puesto para que el diseñador se caiga.

Y sigue siendo mi opinión, el .NET no dejará de ser lo que es hasta que
o
quiten la VM y sea algo nativo o la oculten tanto que apenas sea
detectable. Porque el tema de la portabilidad es una falacia como un
castillo. Una aplicación .NET es tan portable como lo es un EXE nativo
hecho en C++ de toda la vida... Una aplicación MFC se ejecutará en los
mismos lugares que una .NET, y en el tema embedded es lo mismo, si
preparas una aplicación .NET para embebido, también la tienes que
preparar
en MFC.

Pues eso.

On Tue, 02 Jan 2007 14:24:18 +0100, Ana Zuluaga

wrote:

C# lleva ya como 5 años no? Ya deberia estarse usando mas ;)

Sobre Delphi yo no creo que haya muchas aplicaciones de esas que
pregunta el
companero.

De C++ ciertamente creo que es el que mas se usa para eso. Uno puede
verlo
usando reshacker al EXE para ver las librerias que usa.

"Pablo Iglesias" wrote in
message
news:

Hombre... C# es aún muy "joven" como para que pueda tener una base de
aplicaciones instaladas que pueda llegar a compararse, ni siquiera
remotamente, a lenguajes como Delphi, Java o muchísimo menos C++ o VB.

Piensa que por ejemplo en el caso de C++ estamos hablando de un
lenguaje
que
tiene más de 20 años, y no se le han hecho cambios sustanciales como a
Pascal
o Basic...

Saludos

"Alhambra-Eidos" wrote:

Y C# en qué estado queda ?

http://www.alhambra-eidos.com/web2005/index.html


"Pablo Iglesias" wrote:

> Hola Carlos, feliz año :)
>
> El lenguaje en el que estan hechas la mayoría de las aplicaciones
que
> usamos
> a diario, es C++. Seguido de cerca por Visual Basic, Java y quizá
> después
> Delphi (Object Pascal). Para muchas de estas aplicaciones,
realmente,
> se
> utilizan varios lenguajes (por ejemplo, Visual Basic o Delphi para
> crear la
> interfaz de usuario y C++ para crear DLL's que el programa pueda
> necesitar).
>
> Saludos
>
>
> "Carlos" wrote:
>
> > Hola,
> > tengo la curiosidad de saber cual es el lenguaje que normalmente
se
> > usa para
> > programar los softwares utilitarios que uno usa a diario, que
> > adquiere por
> > internet y similares.
> >
> > Gracias
> >
> >
> >

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
>>> Ningún experimento puede reproducirse.

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
> La tragedia de la edad no es ser viejo, sino que se sea joven y la gente
no lo vea.