técnicas del c# comparadas con VFP

11/09/2007 - 22:11 por Germán Valdez | Informe spam
hola a todos.

quisiera saber si en C# existen comandos similares a estos de Visual
Foxpro.

Sustitucion de macros & () o EXECSCRIPT;
(Ejecutar un comando dentro de una variable)

armar cadenas para ser enviadas al SQL con los comandos TEXT ENDTEXT
(Evitar la concatenación con comillas que en grandes instrucciones
confunde).

Armar cursores temporales CREATE CURSOR. con ado.net
(Trabajar con datos en recordset distintos a los originales de la
consulta)

Aún no he visto al C# pero quisiera saber si estos comandos que uso mucho
existen en .net

Preguntas similare

Leer las respuestas

#6 Antonio Rodriguez
16/09/2007 - 20:14 | Informe spam

El C# es algo parecido. Se traduce a un pseudoensamblador. Y encima se
traduce bastante linealmente y mal (es decir, apenas se optimiza). Y luego
se pasa a una máquina virtual que coge ese pseudoensamblador,
supuestamente lo optimiza -pero poco-, lo convierte a código máquina y lo
ejecuta, muy posiblemente de la misma forma: cogiendo el bytecode del MSIL
y llamando a la función dentro del array que lo convertirá en código
máquna. Y luego lo ejecutará.

¿Cuál es la diferencia? Apenas ninguna. Y por tanto, en cuanto a
rendimiento, apenas ninguna variación.




En este caso específico comparandolo con un lenguaje interpretado como VFP
yo creo que la diferencia se nota a favor de éste. No sé a que se deba.
Pero aun fuesen exactamente iguales en velocidad, me beneficia un lenguaje
tan fuertemente tipado cuyo compilador no aprovecha ese hecho? Yo creo que
no.


Sin embargo, otros lenguajes como C++ (ojo, no C++/CLI, aunque le de
10.000 patadas al C#), Pascal, ADA, etc, funcionan de la forma clásica: el
tiempo se pierde en la fase de compilación. En tiempo de ejecución ya está
todo decidido, simplemente se carga y se ejecuta.



Ok una pregunta, el VC++ de .NET funciona así también o es igual que C#?


Pero volviendo al tema de las bases de datos, si abstraemos el lenguaje de
acceso a ellas, el tiempo de ejecución es básicamente el mismo se use el
lenguaje que se use: es una base de datos y más o menos todas trabajan
igual, así que ahí no hay diferencia de rendimiento. La diferencia debe
estar en el lenguaje de la aplicación.




Yo me refería mas al lenguaje mismo que al acceso a los datos pues como
dices el servidor de datos no depende de la aplicación, quizás el otro
participante se refería al manejo de los datos luego que se descargan a los
controles visuales del lenguaje que es donde debe notarse la diferencia.


Oye y gracias por las explicaciones pues aprendi cosas nuevas con tu
mensaje.

Saludos

Antonio Rodriguez
Respuesta Responder a este mensaje
#7 RFOG
16/09/2007 - 20:41 | Informe spam
"Antonio Rodriguez" wrote in message
news:OjxP$1I%
>
El C# es algo parecido. Se traduce a un pseudoensamblador. Y encima se
traduce bastante linealmente y mal (es decir, apenas se optimiza). Y
luego se pasa a una máquina virtual que coge ese pseudoensamblador,
supuestamente lo optimiza -pero poco-, lo convierte a código máquina y lo
ejecuta, muy posiblemente de la misma forma: cogiendo el bytecode del
MSIL y llamando a la función dentro del array que lo convertirá en código
máquna. Y luego lo ejecutará.

¿Cuál es la diferencia? Apenas ninguna. Y por tanto, en cuanto a
rendimiento, apenas ninguna variación.




En este caso específico comparandolo con un lenguaje interpretado como VFP
yo creo que la diferencia se nota a favor de éste. No sé a que se deba.
Pero aun fuesen exactamente iguales en velocidad, me beneficia un lenguaje
tan fuertemente tipado cuyo compilador no aprovecha ese hecho? Yo creo que
no.




A ver, las ventajas de un lenguaje fuertemente tipado están en que el
compilador es capaz de coger más pifias que en uno menos tipado, aparte de
que en ejecución (sea interpretado o no) es algo más rápido ya que no tiene
necesidad de comprobar de qué tipo es una variable. Lo que pasa es que el
compilador del C# es bastante ineficiente a la hora de generar código de
calidad.

De todos modos, los lenguajes fuertemente tipados tienen sus reglas para
aflojar dicho tipado, como los moldeos, los ajustes dinámicos y en el caso
del C++, una simple asignación de punteros con molde (lo que luego pase si
te equivocas es cosa tuya).

A mi de hecho los lenguajes que no sean tipados no me gustan. Si necesito
destipar (qué mal suena), pues destipo, pero siempre quiero que el
compilador coja la mayor cantidad posible de pifias (aunque para los
puristas un lenguaje tipado no sea un lenguaje plenamente OO, pero a mi modo
de ver un lenguaje es una herramienta para realizar una acción y me da igual
si es pura o no: yo lo que quiero es que funcione y me coja el mayor número
de errores posibles).


Sin embargo, otros lenguajes como C++ (ojo, no C++/CLI, aunque le de
10.000 patadas al C#), Pascal, ADA, etc, funcionan de la forma clásica:
el tiempo se pierde en la fase de compilación. En tiempo de ejecución ya
está todo decidido, simplemente se carga y se ejecuta.



Ok una pregunta, el VC++ de .NET funciona así también o es igual que C#?




Ahora, dentro del universo de MS, existen dos C++. El C++ de toda la vida y
el C++/CLI, que es un híbrido de C++ que permite trabajar con el .NET de
forma nativa (es decir, genera código MSIL como el de C#, pero de una
calidad mucho mayor, y cuando necesita ejecutar algo de fuera del .NET, pues
simplemente lo hace y punto). Entre sus muchas ventajas está el que no
necesita -pero permite- el interop mediante atributos y es en muchas cosas
más flexible que el C# y el VB.NET; entre sus desventajas está lo mal que se
integra con el Visual Studio (el compilador está muy bien, pero la
integración es pésima), y que es C++: a poco que te despistes puedes armar
una buena.

Si sabes algo de C++, en mi cutre-página web puedes leer introducciones
sobre el tema (http://rfog.cmact.com/inicio.htm) ahora está caída no sé por
qué, pero en la sección de textos tienes un par de introducciones.


Pero volviendo al tema de las bases de datos, si abstraemos el lenguaje
de acceso a ellas, el tiempo de ejecución es básicamente el mismo se use
el lenguaje que se use: es una base de datos y más o menos todas trabajan
igual, así que ahí no hay diferencia de rendimiento. La diferencia debe
estar en el lenguaje de la aplicación.




Yo me refería mas al lenguaje mismo que al acceso a los datos pues como
dices el servidor de datos no depende de la aplicación, quizás el otro
participante se refería al manejo de los datos luego que se descargan a
los controles visuales del lenguaje que es donde debe notarse la
diferencia.




No, yo me refería a eso, al lenguaje de la aplicación, no al que controla la
base de datos. Es ahí donde el C# podría ganar a todos por goleada pero se
queda en nada, o casi.


Oye y gracias por las explicaciones pues aprendi cosas nuevas con tu
mensaje.




:-)

Saludos

Antonio Rodriguez

Respuesta Responder a este mensaje
#8 Cholo Lennon
17/09/2007 - 19:23 | Informe spam
Y para la lentitud en general, porque yo no veo cual es la tanta ventaja de
tener lenguajes tan estrictamente tipeados con respecto a los flexibles. Hay
que decirle practicamente todo al compilador antes de ejecutar la primera
instruccion.



Son 2 puntos de vista diferentes... cada uno con sus ventajas y desventajas.

Asumiendo lenguaje tipado como un lenguaje estático y a uno no tipado como un
lenguaje dinámico:

Un lenguaje no tipado es más 'fácil' de utilizar. Puedes prototipar algo mucho
más rápidamente. Por lo general estos lenguajes utilizan garbage collectors, lo
cual reduce muchos errores de programación relacionados con el manejo de
recursos. Son más lentos que los lenguajes tipados, aunque con el hardaware de
hoy en día no es tan abismal la diferencia como hace unos años atrás.

Un lenguaje tipado por el contrario ofrece más seguridad en cuanto a los errores
que se pueden producir ya que la idea es atrapar la mayor cantidad de los mismos
en tiempo de compilación. Te imaginas controlar una central nuclear con un
lenguaje que delega todo tu control de errores en tiempo de ejecución??
Excepción no controlada...ups... otro chernobyl... no es que un lenguaje
tipado reduzca a cero la posibilidad de una excepción, pero ayuda. Como muestra
de la 'no reducción a cero', tienes la histórica caida de un cohete Ariane 5 por
culpa de una excepción no controlada en Ada
(http://en.wikipedia.org/wiki/Ariane_5_Flight_501)

Alguien que me diga cuales son esas ventajas. Al principio todos los
lenguajes eran asi (estrictamente tipeados) y con el tiempo dejaron de
serlo, por que habra sido? No me digan que es cierto lo que dijo alguien de
que todo es para poder usar el intelisense ?! No sacrifican otras cosas con
eso? Yo creo que si porque las ventajas en velocidad no se ven.



Lenguajes no tipados han existido desde hace mucho tiempo... te suenan Smalltalk
(creado en el año 1971!) u Objective C (su parte OOP) ???

¿No notas ventajas de velocidad? Quizás no has programado (o visto) sistemas que
manejan miles de transacciones por segundo o que requieren gran poder de
cálculo: Sistemas de telecomunicaciones, de registración de pasajes, sistemas
CAD, simulaciones en física de partículas, simulaciones de Clima, etc, etc. La
mayor parte de las aplicaciones nombradas están hechas en C/C++ (o lenguajes
específicos como Fortran). ¿Eso te dice algo?

Al igual que el amigo RFOG, a mi personalmente me gustan más los lenguajes
estáticos, aunque debo decir que los lenguajes dinámicos tienen lo suyo... (la
gramática de Smalltalk por ejemplo, es tan sencilla... sólo 5 palabras
claves!... sencillo y poderoso...

Salu2


Cholo Lennon
Bs.As.
ARG


"Antonio Rodriguez" wrote in message
news:OQuARRH#
> buscandole similitudes con el VFP. Pero de todas formas, vas a tener que
> trabajar muchisimo y prepararte para la lentitud en el manejo de datos.
> Saludo sy suerte.

Y para la lentitud en general, porque yo no veo cual es la tanta ventaja de
tener lenguajes tan estrictamente tipeados con respecto a los flexibles. Hay
que decirle practicamente todo al compilador antes de ejecutar la primera
instruccion.

Alguien que me diga cuales son esas ventajas. Al principio todos los
lenguajes eran asi (estrictamente tipeados) y con el tiempo dejaron de
serlo, por que habra sido? No me digan que es cierto lo que dijo alguien de
que todo es para poder usar el intelisense ?! No sacrifican otras cosas con
eso? Yo creo que si porque las ventajas en velocidad no se ven.

Antonio Rodriguez





Respuesta Responder a este mensaje
#9 Antonio Rodriguez
17/09/2007 - 20:51 | Informe spam
más rápidamente. Por lo general estos lenguajes utilizan garbage
collectors, lo
cual reduce muchos errores de programación relacionados con el manejo de
recursos. Son más lentos que los lenguajes tipados, aunque con el
hardaware de
hoy en día no es tan abismal la diferencia como hace unos años atrás.




Yo no conozco muchos lenguajes no tipados, me orienté al que conozco bien
que es Visual Foxpro. Como ejemplo tipado el que mas cerca tengo que es C#.
En cuanto a la velocidad te digo que por la experiencia con VFP y ahora con
C# la diferencia es notoria a favor de VFP.

en tiempo de compilación. Te imaginas controlar una central nuclear con un
lenguaje que delega todo tu control de errores en tiempo de ejecución??
Excepción no controlada...ups... otro chernobyl... no es que un lenguaje
tipado reduzca a cero la posibilidad de una excepción, pero ayuda. Como
muestra
de la 'no reducción a cero', tienes la histórica caida de un cohete Ariane
5 por
culpa de una excepción no controlada en Ada



Gracias por el dato pero yo uso lenguajes para aplicaciones comerciales
(gestion, stock, contab, cliente, ...), es decir sistemas corrientes.


que todo es para poder usar el intelisense ?! No sacrifican otras cosas
con
eso? Yo creo que si porque las ventajas en velocidad no se ven.



¿No notas ventajas de velocidad? Quizás no has programado (o visto)
sistemas que
manejan miles de transacciones por segundo o que requieren gran poder de
cálculo: Sistemas de telecomunicaciones, de registración de pasajes,
sistemas
CAD, simulaciones en física de partículas, simulaciones de Clima, etc,
etc. La
mayor parte de las aplicaciones nombradas están hechas en C/C++ (o
lenguajes
específicos como Fortran). ¿Eso te dice algo?



Fuera bueno saber por que no están en C#, que es sobre lo que hablamos
siendo estrictamente tipado también.
Pero sobre si me dice algo, me dice que para quien trabaje con esas
aplicaciones se justifica uno de esos lenguajes pero los que trabajamos con
aplicaciones 'normales' como manejar datos de sistemas de gestion no nos
interesa mucho ese alto nivel de procesamiento. Buscamos fundamentalmente
herramientas RAD que nos simplifiquen la vida , que ayuden optimizar los
costos de desarrollo sobre todo cuando se trabaja en equipos de programación
y también que sean aceptablemente buenas en performance. C#, siendo
fuertemente tipado, lo han mercadeado para eso, solo que decimos que
comparandolo con un no tipado como VFP las ventajas en performance no
existen.
De eso es que estamos hablando no de todo lo demas donde se que tienes
razon.






Saludos

Antonio Rodriguez
Respuesta Responder a este mensaje
#10 Jose Camacho Vaca
18/09/2007 - 01:26 | Informe spam
Perdon por la intromisión, pero yo hasta ahora no he visto un mejor manejo de
datos que el que tiene VFP.
Es simple, ya hice la prueba con C# y su datset, C++ y su famoso datareader.
Ninguno de los 2 siquiera se asemeja en velocidad a un cursor de VFP.
También ya hice la prueba con serialización y con XML y nada. Simplemente
son lentos.
Si alguien conoce alguna herramienta que brinde la misma velocidad en datos
(o al menos similar) que VFP, seria bueno que lo comentara por favor.
Saludos.
José Camacho Vaca
Colima, MX


"Antonio Rodriguez" wrote:

> más rápidamente. Por lo general estos lenguajes utilizan garbage
> collectors, lo
> cual reduce muchos errores de programación relacionados con el manejo de
> recursos. Son más lentos que los lenguajes tipados, aunque con el
> hardaware de
> hoy en día no es tan abismal la diferencia como hace unos años atrás.
>

Yo no conozco muchos lenguajes no tipados, me orienté al que conozco bien
que es Visual Foxpro. Como ejemplo tipado el que mas cerca tengo que es C#.
En cuanto a la velocidad te digo que por la experiencia con VFP y ahora con
C# la diferencia es notoria a favor de VFP.

> en tiempo de compilación. Te imaginas controlar una central nuclear con un
> lenguaje que delega todo tu control de errores en tiempo de ejecución??
> Excepción no controlada...ups... otro chernobyl... no es que un lenguaje
> tipado reduzca a cero la posibilidad de una excepción, pero ayuda. Como
> muestra
> de la 'no reducción a cero', tienes la histórica caida de un cohete Ariane
> 5 por
> culpa de una excepción no controlada en Ada

Gracias por el dato pero yo uso lenguajes para aplicaciones comerciales
(gestion, stock, contab, cliente, ...), es decir sistemas corrientes.

>
>> que todo es para poder usar el intelisense ?! No sacrifican otras cosas
>> con
>> eso? Yo creo que si porque las ventajas en velocidad no se ven.
>
> ¿No notas ventajas de velocidad? Quizás no has programado (o visto)
> sistemas que
> manejan miles de transacciones por segundo o que requieren gran poder de
> cálculo: Sistemas de telecomunicaciones, de registración de pasajes,
> sistemas
> CAD, simulaciones en física de partículas, simulaciones de Clima, etc,
> etc. La
> mayor parte de las aplicaciones nombradas están hechas en C/C++ (o
> lenguajes
> específicos como Fortran). ¿Eso te dice algo?

Fuera bueno saber por que no están en C#, que es sobre lo que hablamos
siendo estrictamente tipado también.
Pero sobre si me dice algo, me dice que para quien trabaje con esas
aplicaciones se justifica uno de esos lenguajes pero los que trabajamos con
aplicaciones 'normales' como manejar datos de sistemas de gestion no nos
interesa mucho ese alto nivel de procesamiento. Buscamos fundamentalmente
herramientas RAD que nos simplifiquen la vida , que ayuden optimizar los
costos de desarrollo sobre todo cuando se trabaja en equipos de programación
y también que sean aceptablemente buenas en performance. C#, siendo
fuertemente tipado, lo han mercadeado para eso, solo que decimos que
comparandolo con un no tipado como VFP las ventajas en performance no
existen.
De eso es que estamos hablando no de todo lo demas donde se que tienes
razon.

>


Saludos

Antonio Rodriguez



Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida