técnicas del c# comparadas con VFP
Germán Valdez
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
principiante
> Sustitucion de macros & () o EXECSCRIPT;
> (Ejecutar un comando dentro de una variable)
>
Se puede aproximar en la versión actual aproximar con una técnica llamada
'Reflexión'.
También en la próxima versión vienen mejoras adicionales relacionadas al
código dinámico con los tipos 'Expression' (trees).
> armar cadenas para ser enviadas al SQL con los comandos TEXT ENDTEXT
> (Evitar la concatenación con comillas que en grandes instrucciones
> confunde).
>
En C# no hay que poner continuadores de líneas como en VFP o VB.
> Armar cursores temporales CREATE CURSOR. con ado.net
> (Trabajar con datos en recordset distintos a los originales de la
> consulta)
>
Se puede en la versión actual pero de una manera más trabajosa y con
limitantes debido a lo fuertemente tipeado que es C#, donde todo es un
objeto. (al menos hasta ahora:) En la próxima versión, sin embargo, vienen
cosas como los tipos anónimos y los tipos implícitos que flexibilizarán
bastante este tema, probablemente porque se dieron cuenta que hay que
flexibilizar!
>
> Aún no he visto al C# pero quisiera saber si estos comandos que uso mucho
> existen en .net
>
Lo primero que debes saber es que es un mundo muy distinto, conviene empezar
desde lo más básico preferiblemente con algún libro o alguno de los muchos
sites que aparecen en la web que poseen artículos sobre cómo hacer la
migración. No te voy a engañar diciéndote que sea fácil el aprendizaje. Es
mucho lo que hay por aprender.
Jose TH
Cholo Lennon
Nuevamente... algo ya posteado
> Sustitucion de macros & () o EXECSCRIPT;
> (Ejecutar un comando dentro de una variable)
http://www.codeproject.com/csharp/evalcscode.asp
--
Cholo Lennon
Bs.As.
ARG
"Germán Valdez" <gfva...@hotmail.com> wrote in message
news:#TRZ$$K9HHA...@TK2MSFTNGP03.phx.gbl...
Jose Camacho Vaca
Cursor, en C# deben ser como unas 30 líneas de código. La verdad C# esta
todavía en pañales, probablemente en la prox. ver. o hasta dentro de varios
años tenga la madurez que tiene VFP, al menos para el manejo de datos.
Mejor utiliza las cosas simples de C#, para que no pierdas tanto tiempo
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.
--
José Camacho Vaca
Colima, MX
Antonio Rodriguez
> 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
RFOG
compilador es pésimo, y el jitter peor todavía.
Hagamos un paralelismo:
Lenguajes como el XBASE se traducen a PCODE, que no es otra cosa que el
código fuente convertido en una especie de "acelerador" en el que en lugar
de leer una cadena se lee una secuencia de bytes que se corresponden en
línea directa con un comando (aunque no sé realmente cómo funciona, si yo
tuviera que hacer algo con PCODE, haría corresponder el bytecode de cada
instrucción con un índice de un array de punteros a funciones que serían el
comando a ejectuar. De ese modo, en un bucle ultrarrápio se puede ejecutar
el programa entero).
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.
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. Pero evidentemente tiene otras
contrapartidas. No puedes acceder fácilmente a tu propio código ejecutable
de forma dinámica (reflexión) -Ojo, poderse, se puede-, y temas como los
genéricos (léase plantillas), a poco que te entusiasmes conviertes el
ejecutable en un monstruo de tamaño.
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.
--
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
========================================
Incluso el pasado puede modificarse; los historiadores no paran de
demostrarlo.
-- Jean Paul Sartre. (1905-1980).
"Antonio Rodriguez" <n...@nos.net> wrote in message
news:OQuARRH%23HH...@TK2MSFTNGP05.phx.gbl...
Antonio Rodriguez
> 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
RFOG
> >
>> 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
>
Cholo Lennon
> 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" <n...@nos.net> wrote in message
news:OQuARRH#HHA...@TK2MSFTNGP05.phx.gbl...
Antonio Rodriguez
> 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
Jose Camacho Vaca
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
Cholo Lennon
> 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.
Deberías aclarar primero que estás comparando: No es lo mismo que VFP acceda a
su base local que C# a un motor relacional como sql server u oracle. Quizás para
ser justos habría que comparar VFP contrar sql server u oracle. Por otro lado
debo decir que si... que VFP es de los más rápidos para el acceso a datos de
manera local. Ojo que C++ no se queda atrás con su biblioteca ATL y sus clases
para manejo de clientes OleDB. A nivel de esta capa de abstracción es lo más
rápido que hay. De hecho proveedores OleDB se hacen con esta biblioteca. Una
comparación que se podría hacer es C++ con ATL accesando una base de VFP
mediante un controlador OleDB. En este caso sospecho que VFP puede salir
ganador, pero no por mucho, porque no tiene la capa de abstracción de OleDB.
Quedaría por probar algo similiar: Accesar desde C++/ATL una base Access y
comparar contra VFP accesando sus datos nativos. Esto podría tener mejores
resultados en cuanto a C++ ya que entre otras cosas el motor Jet usa la misma
tecnología 'rushmore' que VFP. Como punto en contra de C++ ATL es que son clases
de bajo nivel. No es tan sencillo de usar como VFP o como ADO.
Como verás he tratado de no sacar a VFP del acceso a sus datos nativos. Todo
cambia si el mismo debe acceder mediante OleDB a otros datos... aquí se equipara
más la cosa.
Una aclaración sobre VFP y C#: Las comparaciones son odiosas, pero me parece que
quizás es medio a la ligera hacer estas comparaciones: VFP es claramente un
lenguaje orientado a datos, siempre lo fue y ha tenido una evolución constante
desde hace muchos años. C# por el contrario es un lenguaje de propósito general,
su objetivo es más amplio. Además el lenguaje es más rico sintácticamente
hablando. Hay muchos tipos de aplicaciones para las que C# está mejor preparado
que VFP, incluso algunas orientadas a datos. Así y todo no descarto a VFP por
varias razones, algunas históricas :-) (he programado en lenguajes xBase desde
DBase II).
Un última cosa: VFP y C# son 2 lenguajes claramente distintos, con sus propios
idiomas, no hay que basarse en esto para hacer comparaciones: Por ejemplo: Si
VFP permite macro sustituciones con un simple operador esto no hace que C# se
malo... hay muchas maneras de conseguir lo mismo. No hay que trasladar de manera
tan literal formas de programar de un lenguaje a otro. Esto puede ser el punto
de partida para programar realmente mal.
>
> C++ y su famoso datareader
>
Esto es C++ CLI con Ado.Net... no C++, son 2 lenguajes distintos...
Salu2
--
Cholo Lennon
Bs.As.
ARG
"Jose Camacho Vaca" <JoseCam...@discussions.microsoft.com> wrote in message
news:3B841307-77A8-4F04...@microsoft.com...
principiante
Mira, yo uso VFP9 con SQL Server usando ODBC y la tecnica llamada SQL Pass
Through donde uno le pasa las instrucciones al servidor como una cadena con
una simple instrucción: SQLEXEC(). De la velocidad te puedo decir que es lo
más rápido, simple y estable que he visto en mi vida. Tengo sistemas
funcionando asi desde el 2005 y a veces hasta 'me aburre' su estabilidad y
gran rendimiento ;-) Sencillamente los problemas que me ha dado han sido
los pequeños tipicos errores de programación que a todos nos pasan. Algunos
dicen ODBC es obsoleto pero no es que lo sea sino que no tiene nada que
actualizar y siempre seguirá usandose, de hecho se usa en muchas mas cosas
de lo que pensamos.
Pero tambien lo he usado con OleDB y aunque es un poquito mas lento que con
ODBC, en ambos casos la velocidad que he visto es mas rápida (se nota) que
C# y su ADO.NET, con el cual se ha estado comparando aquí. Tambien sobre el
lenguaje mismo en el lado del cliente, VFP aunque es un lenguaje 'dinamico'
es sorprendente rápido. Estoy de acuerdo con quien dice que si me van a
forzar a un lenguaje fuertemente tipeado pues es de esperarse que su
rendimiento lo justifique. En C#, lamentablemente no es el caso ya que en
su velocidad no se nota la ventaja de ser fuertemente tipado. Por supuesto
que no digo que no haya otras ventajas, ya que la hay.
Las razones de porque VFP destaca por su rapidez? nadie las sabe
explicar.... pero VFP desde hace tiempo siempre ha sido famoso por su
velocidad, no solo con sus bases nativas sino tambien en ambiente de
cliente/servidor como se ha demostrado.
Eso es en cuanto al tema de manejo de datos, el cual siempre ha sido la
especializacion de VFP porque en otros temas C# y .NET son superiores sin
ninguna duda. Pero comparar la sintaxis es algo engorroso por el mismo
hecho de que uno es tipeado y el otro no.
Y si muchos de VFP (y de Delphi tambien como es mi caso) andamos en el mundo
de .NET no es solo porque queramos sino, para quienes no lo saben, porque
VFP va a desaparacer despues de la version actual. Asi lo quiso Microsoft a
pesar de las protestas de la comunidad. En cuanto a Delphi tambien va poco
a poco en declive. De nuevo MicroSoft nos impone el rumbo :(
De algo similar se hablaba en otro hilo.
José TH
Jose Camacho Vaca
parece que no tiene respuesta todavía. Alguien conoce alguna herramienta,
librería o truco que haga que C# maneje sus datasets o datareaders o lo que
sea de una manera rápida y ágil como lo hace VFP con sus cursores?
La verdad eso es lo que realmente me interesa. Gracias a todos por su ayuda
y reciban un saludo.
--
José Camacho Vaca
Colima, MX
principiante
> parece que no tiene respuesta todavía. Alguien conoce alguna herramienta,
> librería o truco que haga que C# maneje sus datasets o datareaders o lo
> que
> sea de una manera rápida y ágil como lo hace VFP con sus cursores?
Eso es muy dificil porque los datasets (tipados) generan un monton de codigo
auto-generado que generan un algo overhead.
Rafael
Saludos
Rafael
"Cholo Lennon" <cholo...@hotmail.com> escribió en el mensaje
news:%23cGKzrm%23HHA...@TK2MSFTNGP04.phx.gbl...
> No he probado la versión para .Net de esta biblioteca pero siempre he
> tenido buenas referencias de la versión nativa para C++
>
> OleDbProNet
> http://www.udaparts.com/products.htm
>
> Podrías probarla y contarnos los resultados :-)
> Dificilmente supere a VFP ya que este tiene un motor nativo y sin capas
> intermedias, pero quizás sea un gran avance en velocidad sobre Ado.Net.
>
> Salu2
>
> --
> Cholo Lennon
> Bs.As.
> ARG
>
> "Jose Camacho Vaca" <JoseCam...@discussions.microsoft.com> escribió
> en el mensaje news:AE7D8325-35BD-4C49...@microsoft.com...
Rafael
hasta para un dataset con una tablita con dos campos) que si uno lo ve
incluye muchas cosas genéricas no específicas. El resultado es un overhead,
eso es parte del problema de lentitud de que se ha estado hablando.
Yo muchas veces, no siempre, prefiero hacer algunas cosas de forma manual
precisamente para evitar en parte ese codigo excesivo.
Saludos
Rafael
"principiante" <nad...@denada.com> escribió en el mensaje
news:ej3m7zk%23HHA...@TK2MSFTNGP02.phx.gbl...
Cholo Lennon
lenguaje base es C/C++ :-)
Salu2
--
Cholo Lennon
Bs.As.
ARG
"Rafael" <rafaelro...@hotmail.com> wrote in message
news:#QvB53q#HHA....@TK2MSFTNGP02.phx.gbl...
Jose Luis
Que tipo de aplicaciones hace usted?
JL
"Cholo Lennon" <cholo...@hotmail.com> wrote in message
news:eLO29qr%23HHA...@TK2MSFTNGP03.phx.gbl...
Cholo Lennon
se enseña en muchísimos lugares, C++ es tan productivo como cualquier otro.
Además posee un nivel de abstracción superior a la mayoría ya que permite
múltiples paradigmas de programación. Para mi es un 'placer' programar en
C++ y para nada trabajoso :-) eso si, no voy a discutir que formar un
programador productivo en C++ lleva mucho más tiempo que en Java o C#.
Por cierto... trabajo en una empresa de telecomunicaciones. El core de las
aplicaciones (distribuidas la gran mayoría) se hace en C++. La capa de
interacción con el usuario se desarrolla en Java y/o C#; más no puedo decir
;-)
Salu2
--
Cholo Lennon
Bs.As.
ARG
"Jose Luis" <x> escribió en el mensaje
news:uhPqrzw%23HH...@TK2MSFTNGP06.phx.gbl...
Alfredo Novoa
Hola Cholo,
On Thu, 20 Sep 2007 02:43:29 -0300, "Cholo Lennon"
<cholo...@hotmail.com> wrote:
>Además posee un nivel de abstracción superior a la mayoría ya que permite
>múltiples paradigmas de programación.
Eso no tiene nada que ver con el nivel de abstracción. Además casi
todos los lenguajes permiten eso.
Saludos
Alfredo
Cholo Lennon
del lenguaje:
¿Como que la multiplicidad de paradigmas no permite poseer un mayor nivel de
abstracción? Hay muchas características que ayudan a generar un mayor nivel de
abstracción, una de ellas es el soporte multiparadigma. Es decir permitr
programación estructurada, permitir programación orientada a objetos, permitir
programación genérica y permitir abastracción de datos. La programación genérica
por ejemplo (y estoy hablando de templates, no generics) permite en C++ muchas
cosas impensadas en tus 'casi todos los lenguajes'. ¿Conoces bibliotecas como
STL, boost::MPL o boost::Lamba por nombrar algunas? La primera tiene una forma
clara de separar contenedores de los algoritmos que operan los mismos, en gran
medidad debido a templates, a programación estructurada y OOP; además del
soporte para múltiple herencia. La segunda permite metaprogramación (algo de
seguro desconocido a la mayoría de los programadores). Esto debido también a
templates, programación estructura y OOP. Por último boost::Lambda permite
programación funcional, si,expresiones lambda en un lenguaje que no está pensado
para ello. Deberías ver bibliotecas como blitz++. La sobrecarga de operadores,
templates, metaprogramación y OOP la hacen una biblioteca matemática de altísimo
rendimiento, comparable a fortran, pero con una sencillez de uso asombrosa. Todo
parece natural, matemáticamente hablando claro está.
Todo lo que te nombro es sólo una parte. El asunto es que entre otras cosas, el
nivel de abstracción que se logra en C++ es superior a la mayoría (el lenguaje D
es otro simpatico lenguaje con dichas habilidades), debido en gran medida a su
capacidad multiparadigma, aunque también a otras características como las
citadas herencia múltiple y sobrecarga de operadores. Además y por si esto fuera
poco, lo más importante (por lo menos para los que programamos en C++): la
abstracción se logra en gran parte a muy bajo o cero costo en cuanto a
rendimiento.
Salu2
PD: Para no alargar esto, que me parece se va de tema en este grupo, sería bueno
seguir intercambiando opiniones en el foro de VC++ (microsoft.public.es.vc)
--
Cholo Lennon
Bs.As.
ARG
"Alfredo Novoa" <alfred...@hotmail.com> wrote in message
news:5fk4f3tmsl0a6scmh...@4ax.com...
Alfredo Novoa
Parece que desconoces lo que significa "nivel de abstracción". El
nivel de abstracción de un lenguaje significa a grandes rasgos el
alejamiento del lenguaje máquina.
No tiene absolutamente nada que ver con lo que dices. Es más C++ tiene
elementos de muy bajo nivel y nada que se acerque al alto nivel de
lenguajes como Prolog o SQL.
> Es decir permitr
>programación estructurada, permitir programación orientada a objetos, permitir
>programación genérica y permitir abastracción de datos.
Todo esto se puede hacer con C# y Java, y la programación espagueti
también. Además la programación genérica no es ningún paradigma, y
quitando esto ya entran prácticamente todos los lenguajes. Se puede
hacer programación OO y espagueti en Pascal y C.
La abstracción de datos así dicho tan vagamente la permiten todos los
lenguajes hasta el ensamblador.
> permite en C++ muchas
>cosas impensadas en tus 'casi todos los lenguajes'. ¿Conoces bibliotecas como
>STL, boost::MPL o boost::Lamba por nombrar algunas? La primera tiene una forma
>clara de separar contenedores de los algoritmos que operan los mismos,
Muy primitivo comparado a un SGBD por ejemplo. No digo que no tenga
sus usos, pero no hay punto de comparación entre el nivel de
abstracción de una biblioteca de contenedores y un SGBD SQL de gama
alta.
> en gran
>medidad debido a templates, a programación estructurada y OOP; además del
>soporte para múltiple herencia.
Soporte que hace aguas por todas partes y que casi nadie quiere
llevarse a otros lenguajes.
> La segunda permite metaprogramación (algo de
>seguro desconocido a la mayoría de los programadores). Esto debido también a
>templates, programación estructura y OOP. Por último boost::Lambda permite
>programación funcional, si,expresiones lambda en un lenguaje que no está pensado
>para ello.
Nada fuera de lo común. Siempre puedes crear unas bibilotecas que te
permitan hacer un tipo de programación distinto en cualquier lenguaje.
> Deberías ver bibliotecas como blitz++. La sobrecarga de operadores,
>templates, metaprogramación y OOP la hacen una biblioteca matemática de altísimo
>rendimiento, comparable a fortran, pero con una sencillez de uso asombrosa. Todo
>parece natural, matemáticamente hablando claro está.
Pues lo acabo de mirar y parece de bastante bajo nivel si lo comparas
con lenguajes como Mathematica o Maple. Tampoco parece difícil hacer
algo parecido en C#.
>Todo lo que te nombro es sólo una parte. El asunto es que entre otras cosas, el
>nivel de abstracción que se logra en C++ es superior a la mayoría
Cualquier lenguajillo de generación de informes está muy por encima en
nivel de abstracción. Está bastante claro que no conoces el
significado del concepto.
Saludos
Cholo Lennon
> On Thu, 20 Sep 2007 10:30:45 -0300, "Cholo Lennon"
> <cholo...@hotmail.com> wrote:
>
> >Debo disentir enormemente con lo que dices y según creo es por
desconocimiento
> >del lenguaje:
> >
> >¿Como que la multiplicidad de paradigmas no permite poseer un mayor nivel de
> >abstracción? Hay muchas características que ayudan a generar un mayor nivel
de
> >abstracción, una de ellas es el soporte multiparadigma.
>
> Parece que desconoces lo que significa "nivel de abstracción". El
> nivel de abstracción de un lenguaje significa a grandes rasgos el
> alejamiento del lenguaje máquina.
>
> No tiene absolutamente nada que ver con lo que dices. Es más C++ tiene
> elementos de muy bajo nivel y nada que se acerque al alto nivel de
> lenguajes como Prolog o SQL.
>
Pues parece que tu tampoco.
Que C++ tenga cosas de bajo nivel no significa que no pueda tener cosas de alto
nivel! Una clase es de bajo nivel? Un contenedor STL es de bajo nivel? Se acerca
a ensamblador? mmm... parece que no...
>
> > Es decir permitr
> >programación estructurada, permitir programación orientada a objetos,
permitir
> >programación genérica y permitir abastracción de datos.
>
> Todo esto se puede hacer con C# y Java, y la programación espagueti
> también. Además la programación genérica no es ningún paradigma, y
> quitando esto ya entran prácticamente todos los lenguajes. Se puede
> hacer programación OO y espagueti en Pascal y C.
>
> La abstracción de datos así dicho tan vagamente la permiten todos los
> lenguajes hasta el ensamblador.
1- Claro con ese punto de vista podemos programar directamente en ensamblador,
total... no hay nada que no se pueda hacer con él....
2- Para tu información sobre los paradigmas:
http://en.wikipedia.org/wiki/Programming_paradigm. Me extraña que digas que la
programación genérica no es un paradigma. El concepto es bastante antiguo y está
documentado en infinidad de bibliografías.
>
> > permite en C++ muchas
> >cosas impensadas en tus 'casi todos los lenguajes'. ¿Conoces bibliotecas como
> >STL, boost::MPL o boost::Lamba por nombrar algunas? La primera tiene una
forma
> >clara de separar contenedores de los algoritmos que operan los mismos,
>
> Muy primitivo comparado a un SGBD por ejemplo. No digo que no tenga
> sus usos, pero no hay punto de comparación entre el nivel de
> abstracción de una biblioteca de contenedores y un SGBD SQL de gama
> alta.
>
> > en gran
> >medidad debido a templates, a programación estructurada y OOP; además del
> >soporte para múltiple herencia.
>
Estoy comparando lenguajes de nivel similar, es decir lenguajes de propóstio
general... no tiene sentido comparar C++ con SQL!!, a quien se le ocurriría?!
Estás mezclando peras con bananas...
>
> Soporte que hace aguas por todas partes y que casi nadie quiere
> llevarse a otros lenguajes.
>
Ja! es lo más gracioso que he escuchado...
Java y C# tienen hoy generics gracias al exito de los templates en C++ y su
biblioteca STL.
Aguas por todos lados? El mecanismo no será perfecto (si perfectible) pero en
los ultimás 10 años la mayor parte de los componentes COM han sido construidos
con ATL (Active Template Library). Los módulos de la Nasa Spirit y Opportunity
en Marte tienen una biblioteca de compresion de datos en C++ basada en
templates. STL y templates son claves hoy toda programación C++.
>
> > La segunda permite metaprogramación (algo de
> >seguro desconocido a la mayoría de los programadores). Esto debido también a
> >templates, programación estructura y OOP. Por último boost::Lambda permite
> >programación funcional, si,expresiones lambda en un lenguaje que no está
pensado
> >para ello.
>
> Nada fuera de lo común. Siempre puedes crear unas bibilotecas que te
> permitan hacer un tipo de programación distinto en cualquier lenguaje.
>
Si claro... metaprogramación o expresiones lambda en Java o C#. Necesitas
extender el lenguaje para ello (como está claro que sucederá con C#
próximamente). Por otro lado como haces desde una biblioteca para permitir un
tipo de programación si el lenguaje no lo soporta? Si un lenguaje no tiene
soporte para programación genérica, como haces desde una biblioteca para
permitir eso????
>
> > Deberías ver bibliotecas como blitz++. La sobrecarga de operadores,
> >templates, metaprogramación y OOP la hacen una biblioteca matemática de
altísimo
> >rendimiento, comparable a fortran, pero con una sencillez de uso asombrosa.
Todo
> >parece natural, matemáticamente hablando claro está.
>
> Pues lo acabo de mirar y parece de bastante bajo nivel si lo comparas
> con lenguajes como Mathematica o Maple.
>
Otra vez lo mismo...comparas peras con bananas... C++ contra Maple o
Mathematica, son 2 cosas totalmente distintas. Con tu mismo razonamiento podría
poner puntos en contra de Maple porque no puedes construir un driver con él.
>
> Tampoco parece difícil hacer algo parecido en C#.
>
Te quiero ver con una biblioteca matemática de alto rendimiento en C#.
>
> >Todo lo que te nombro es sólo una parte. El asunto es que entre otras cosas,
el
> >nivel de abstracción que se logra en C++ es superior a la mayoría
>
> Cualquier lenguajillo de generación de informes está muy por encima en
> nivel de abstracción.
>
Nuevamente lo mismo... a la 'mayoría' me refiero con lenguajes similares de
propósito general. Como voy a comparar C++ con un lenguaje de generación de
reportes??
Lo que tiene que quedar claro es que C++ no será el mejor en todos los rubros,
pero es muy genérico, lo cual le permite abarcar bastantes rubros con un
comportamiento decente en todos ellos.
> Está bastante claro que no conoces el significado del concepto.
Ahh... gracias por tu nivel de arrogancia...
Alfredo Novoa
<cholo...@hotmail.com> wrote:
>> No tiene absolutamente nada que ver con lo que dices. Es más C++ tiene
>> elementos de muy bajo nivel y nada que se acerque al alto nivel de
>> lenguajes como Prolog o SQL.
>>
>
>Pues parece que tu tampoco.
>Que C++ tenga cosas de bajo nivel no significa que no pueda tener cosas de alto
>nivel!
No, pero el caso es que no tiene mucha cosa de alto nivel, y haciendo
la media se queda bastante abajo comparado con muchos lenguajes.
Está claro que un lenguaje que solo tiene cosas de alto nivel es de
más alto nivel que uno que tiene cosas de alto nivel y cosas de bajo
nivel.
> Una clase es de bajo nivel? Un contenedor STL es de bajo nivel? Se acerca
>a ensamblador? mmm... parece que no...
Depende con que los compares. Si comparas una clase o un contenedor
STL con una tabla de Oracle o DB2 entonces son de muy bajo nivel.
Las plantillas no es que sean una cosa de muy alto nivel precisamente.
>> La abstracción de datos así dicho tan vagamente la permiten todos los
>> lenguajes hasta el ensamblador.
>
>1- Claro con ese punto de vista podemos programar directamente en ensamblador,
>total... no hay nada que no se pueda hacer con él....
No lo has entendido. Lo que digo no tiene nada que ver con eso. Me
refiero a que hasta el ensamblador permite "abstracción de datos".
Todos los lenguajes la permiten, es una de las razones fundamentales
de su existencia.
>2- Para tu información sobre los paradigmas:
>http://en.wikipedia.org/wiki/Programming_paradigm. Me extraña que digas que la
>programación genérica no es un paradigma.
No lo es. Es solo una característica. Sería como decir que la herencia
múltiple es un paradigma o que los multimétodos son un paradigma.
> El concepto es bastante antiguo y está
>documentado en infinidad de bibliografías.
Cosa que no tiene nada que ver con ser un paradigma.
>> > en gran
>> >medidad debido a templates, a programación estructurada y OOP; además del
>> >soporte para múltiple herencia.
>>
>
>Estoy comparando lenguajes de nivel similar, es decir lenguajes de propóstio
>general...
Pues haberlo dicho.
Supongo que aquí "nivel" no tiene nada que ver con nivel de
abstracción, por que sino apaga y vámonos :-)
> no tiene sentido comparar C++ con SQL!!, a quien se le ocurriría?!
¿Y por que no?
Son dos lenguajes de programación y estamos hablando sobre lenguajes
de programación.
>Estás mezclando peras con bananas...
Lenguajes de programación con lenguajes de programación.
Pero de todas formas aun dentro de los lenguajes de propósito general
C++ no es ni mucho menos uno de los que tienen mayor nivel de
abstracción.
Cada vez tengo más claro que estás confundiendo "nivel de abstracción"
con "versatilidad".
C++ es uno de los lenguajes más versátiles y en buena parte es gracias
a tener un nivel de abstracción bastante bajo.
Versatilidad y nivel de abstracción son dos cosas bastante
antagónicas.
>> Soporte que hace aguas por todas partes y que casi nadie quiere
>> llevarse a otros lenguajes.
>>
>
>Ja! es lo más gracioso que he escuchado...
>Java y C# tienen hoy generics gracias al exito de los templates en C++ y su
>biblioteca STL.
Me refería específicamente al modelo de herencia múltiple de C++ y a
nada más. Si nadie lo ha querido copiar es por algo.
>> Nada fuera de lo común. Siempre puedes crear unas bibilotecas que te
>> permitan hacer un tipo de programación distinto en cualquier lenguaje.
>
>Si claro... metaprogramación o expresiones lambda en Java o C#. Necesitas
>extender el lenguaje para ello (como está claro que sucederá con C#
>próximamente). Por otro lado como haces desde una biblioteca para permitir un
>tipo de programación si el lenguaje no lo soporta?
Pues como hacen las bibliotecas que comentas o usando una biblioteca
de bases de datos para hacer programación relacional, por ejemplo.
> Si un lenguaje no tiene
>soporte para programación genérica, como haces desde una biblioteca para
>permitir eso????
La programación genérica no es un tipo de programación, es solo una
característica como otra cualquiera. Para permitirla ni siquiera hacen
falta bibliotecas, solo se necesitaría crear plantillas y usar un
preprocesador.
>Nuevamente lo mismo... a la 'mayoría' me refiero con lenguajes similares de
>propósito general. Como voy a comparar C++ con un lenguaje de generación de
>reportes??
>Lo que tiene que quedar claro es que C++ no será el mejor en todos los rubros,
>pero es muy genérico, lo cual le permite abarcar bastantes rubros con un
>comportamiento decente en todos ellos.
Eso se llama versatilidad, no nivel de abstracción.
>> Está bastante claro que no conoces el significado del concepto.
>
>Ahh... gracias por tu nivel de arrogancia...
Vaya, parece que tampoco conoces el significado de ese concepto :-)
Saludos
Carlos M. Calvelo
> "Alfredo Novoa" <alfredo_no...@hotmail.com> wrote in message
>
> news:sl25f3tmrvjs81rvs...@4ax.com...
>
>
>
>
>
> > On Thu, 20 Sep 2007 10:30:45 -0300, "Cholo Lennon"
> > <chololen...@hotmail.com> wrote:
>
> > >Debo disentir enormemente con lo que dices y según creo es por
> desconocimiento
> > >del lenguaje:
>
> > >¿Como que la multiplicidad de paradigmas no permite poseer un mayor nivel de
> > >abstracción? Hay muchas características que ayudan a generar un mayor nivel
> de
> > >abstracción, una de ellas es el soporte multiparadigma.
>
> > Parece que desconoces lo que significa "nivel de abstracción". El
> > nivel de abstracción de un lenguaje significa a grandes rasgos el
> > alejamiento del lenguaje máquina.
>
> > No tiene absolutamente nada que ver con lo que dices. Es más C++ tiene
> > elementos de muy bajo nivel y nada que se acerque al alto nivel de
> > lenguajes como Prolog o SQL.
>
> Pues parece que tu tampoco.
> Que C++ tenga cosas de bajo nivel no significa que no pueda tener cosas de alto
> nivel!
Y que tenga cosas de alto nivel no lo trasforma en un
lenguage de alto nivel.
Abstraer es precisamente omitir detalles que dificultan
la tarea de concertrarnos en un aspecto determinado.
> Una clase es de bajo nivel? Un contenedor STL es de bajo nivel?
Comparados con qué y con que propósito?
Si la solución a un problema se puede expresar mejor en OO que
en otro tipo de 'abstración', entonces clases son del nivel
adecuado, ni alto ni bajo.
> Se acerca
> a ensamblador? mmm... parece que no...
>
>
>
>
>
> > > Es decir permitr
> > >programación estructurada, permitir programación orientada a objetos,
> permitir
> > >programación genérica y permitir abastracción de datos.
>
> > Todo esto se puede hacer con C# y Java, y la programación espagueti
> > también. Además la programación genérica no es ningún paradigma, y
> > quitando esto ya entran prácticamente todos los lenguajes. Se puede
> > hacer programación OO y espagueti en Pascal y C.
>
> > La abstracción de datos así dicho tan vagamente la permiten todos los
> > lenguajes hasta el ensamblador.
>
> 1- Claro con ese punto de vista podemos programar directamente en ensamblador,
> total... no hay nada que no se pueda hacer con él....
En teoría se podría programar en ensamblador a cualquier nivel
de abstracción que uno se pueda imaginar. En la práctica
el factor limitante es el programador, que, luchando contra
el tiempo, con un problema lo suficientemente complicado,
no podrá abarcar tantos niveles de abstracción a la vez
(o la distancia entre ellos).
> 2- Para tu información sobre los paradigmas:http://en.wikipedia.org/wiki/Programming_paradigm. Me extraña que digas que la
> programación genérica no es un paradigma. El concepto es bastante antiguo y está
> documentado en infinidad de bibliografías.
>
>
>
>
>
>
>
>
> > > permite en C++ muchas
> > >cosas impensadas en tus 'casi todos los lenguajes'. ¿Conoces bibliotecas como
> > >STL, boost::MPL o boost::Lamba por nombrar algunas? La primera tiene una
> forma
> > >clara de separar contenedores de los algoritmos que operan los mismos,
>
> > Muy primitivo comparado a un SGBD por ejemplo. No digo que no tenga
> > sus usos, pero no hay punto de comparación entre el nivel de
> > abstracción de una biblioteca de contenedores y un SGBD SQL de gama
> > alta.
>
> > > en gran
> > >medidad debido a templates, a programación estructurada y OOP; además del
> > >soporte para múltiple herencia.
>
> Estoy comparando lenguajes de nivel similar, es decir lenguajes de propóstio
> general... no tiene sentido comparar C++ con SQL!!, a quien se le ocurriría?!
> Estás mezclando peras con bananas...
>
>
Lenguages de niveles *similares* tienen mas o menos niveles de
abstracción, pues eso... similares.
Si se buscan diferentes niveles de abstracción no parece muy
inteligente comparar *peras* con *peras* entonces.
Si quieres hablar de distintos niveles de abstraccion no se compara
C++ con Java. (Aunque yo me atrevo a insinuar que Java es de un
nivel *ligeramente* mas alto de abstracción). Lo comparas entonces
con ensamblador (mas bajo nivel) o con SQL (mucho mas alto nivel),
por poner dos ejemplos.
O por mi parte con Excel (también mucho mas alto nivel).
Se oyen susurros...
[ Ohhhh! Ha dicho Excel!!! Que barbaridad!!! ]
>
> > Soporte que hace aguas por todas partes y que casi nadie quiere
> > llevarse a otros lenguajes.
>
> Ja! es lo más gracioso que he escuchado...
En filosofía, el tema de ontologías es bastante problemático.
Y tu crees que la informática ya ha encontrado la solución?
Quizás tengan los ontólogos que estudiar C++ y herencia múltiple
y sus problemas desapareceran. Yo creo que lo mas problable es que
a mas de uno le dé risa.
> Java y C# tienen hoy generics gracias al exito de los templates en C++ y su
> biblioteca STL.
> Aguas por todos lados? El mecanismo no será perfecto (si perfectible) pero en
> los ultimás 10 años la mayor parte de los componentes COM han sido construidos
> con ATL (Active Template Library). Los módulos de la Nasa Spirit y Opportunity
> en Marte tienen una biblioteca de compresion de datos en C++ basada en
> templates. STL y templates son claves hoy toda programación C++.
>
>
>
>
>
> > > La segunda permite metaprogramación (algo de
> > >seguro desconocido a la mayoría de los programadores). Esto debido también a
> > >templates, programación estructura y OOP. Por último boost::Lambda permite
> > >programación funcional, si,expresiones lambda en un lenguaje que no está
> pensado
> > >para ello.
>
> > Nada fuera de lo común. Siempre puedes crear unas bibilotecas que te
> > permitan hacer un tipo de programación distinto en cualquier lenguaje.
>
> Si claro... metaprogramación o expresiones lambda en Java o C#. Necesitas
> extender el lenguaje para ello (como está claro que sucederá con C#
> próximamente).
Extender un lenguaje sin sacarle las construcciones de
nivel bajo, no hará que el lenguage sea de un nivel de abstracción
mas alto. Lo que le dan las nuevas construcciónes de alto nivel se
lo quita el aumento en divesidad/complejidad.
Abstaer es lo contrario de 'extender', es 'reducir'.
> Por otro lado como haces desde una biblioteca para permitir un
> tipo de programación si el lenguaje no lo soporta? Si un lenguaje no tiene
> soporte para programación genérica, como haces desde una biblioteca para
> permitir eso????
>
>
>
>
>
> > > Deberías ver bibliotecas como blitz++. La sobrecarga de operadores,
> > >templates, metaprogramación y OOP la hacen una biblioteca matemática de
> altísimo
> > >rendimiento, comparable a fortran, pero con una sencillez de uso asombrosa.
> Todo
> > >parece natural, matemáticamente hablando claro está.
>
> > Pues lo acabo de mirar y parece de bastante bajo nivel si lo comparas
> > con lenguajes como Mathematica o Maple.
>
> Otra vez lo mismo...comparas peras con bananas...
Es la segunda vez que dices la misma tontería. Pero tu si quieres
comparar niveles de abstracción estarás haciendo el ridiculo
comparando lenguages que es este aspecto son iguales, por muy
diferentes que sean en otros.
> C++ contra Maple o
> Mathematica, son 2 cosas totalmente distintas. Con tu mismo razonamiento podría
> poner puntos en contra de Maple porque no puedes construir un driver con él.
>
>
Por eso es de un nivel mas alto de abstracción. Se han eliminado
los detalles que no tienen relación directa alguna con los
conceptos que aparecen en las soluciones de determinados problemas.
Y se han introducido construcciones que si representan estos
conceptos.
>
> > Tampoco parece difícil hacer algo parecido en C#.
>
> Te quiero ver con una biblioteca matemática de alto rendimiento en C#.
>
>
>
>
>
> > >Todo lo que te nombro es sólo una parte. El asunto es que entre otras cosas,
> el
> > >nivel de abstracción que se logra en C++ es superior a la mayoría
>
> > Cualquier lenguajillo de generación de informes está muy por encima en
> > nivel de abstracción.
>
> Nuevamente lo mismo... a la 'mayoría' me refiero con lenguajes similares de
> propósito general. Como voy a comparar C++ con un lenguaje de generación de
> reportes??
Nuevamente...
Lenguages 'similares' tienen niveles de abstracción siminales.
No hay mucho que comparar en ese aspecto. A no ser que lo que
se quiere es demostrar lo similares que son.
> Lo que tiene que quedar claro es que C++ no será el mejor en todos los rubros,
> pero es muy genérico, lo cual le permite abarcar bastantes rubros con un
> comportamiento decente en todos ellos.
Pues esto podría explicarse como un muy bajo nivel de abstracción.
>
> > Está bastante claro que no conoces el significado del concepto.
>
> Ahh... gracias por tu nivel de arrogancia...
>
Pues has demostrado ampliamente que tiene razón;
independientemente de cuanta arrogancia creas tu que
está exponiendo.
No tiene nada de malo no conocer el significado del concepto.
Lo malo es, después de que alguien lo haya puntualizado,
seguir defendiendo esa interpretación erronea del mismo.
Lo del Excel a mas de uno le va a chocar mucho.. y por eso
la incertudumbre en cuanto a qué 'cualidades' se me van a
atribuir ahora a mi, me llena de emoción :)
Saludos,
Carlos
Juan Diego Bueno
> Que C++ tenga cosas de bajo nivel no significa que no pueda tener cosas de
> alto
> nivel!
>Y que tenga cosas de alto nivel no lo trasforma en un
>lenguage de alto nivel.
¿Y si lo dejamos en lenguaje de medio nivel? Solución salomónica. Hace años
yo vi en un libro calificar a C y C++ como lenguajes de medio nivel.
>O por mi parte con Excel (también mucho mas alto nivel).
>Lo del Excel a mas de uno le va a chocar mucho.. y por eso
>la incertudumbre en cuanto a qué 'cualidades' se me van a
>atribuir ahora a mi, me llena de emoción :)
Abstracto no se si será, pero comparar Excel con C++ es de un
surrealista.... ;)
HEREJE!!!!!!!
Creo que vas a ir directo a la hoguera, a la de tus emociones, claro
Saludos