delphi xe4 la proxima semana

[avmm2004]

Parece que vamos a tener delphi xe4 la próxima semana segun Andreano en : http://www.delphifeeds.com/go/s/102992

No viene Android pero si trae Ipad, iphone e Ios por lo menos me resuelve algo.
Si tuviera ya Android sería la BOMBA.

[rretamar]

Y seguimos sacando "versiones" a razón de una o dos por año. Otro producto "nuevo y mejorado", otra licencia, volver a pagar. A seguir en la misma, a continuar exprimiendo a la vaca, aunque leche para sacarle va quedando cada vez menos.

[cmm07]

Esta loco embarcadero, nose en que estan pensando, si solo viene el soporte a ios y firedac yo la hubiera sacado como update, en vez de atraer a la gente, la esta espantando, que lastima :(

[TOPX]

Espero que no sea cierto que lanzarán XE5 el 7 de Septiembre... :(

XE4 and XE5 release dates? | Delphi Haters (http://delphihaters.blogspot.com/2013/04/xe4-and-xe5-release-dates.html)

-

[gatosoft]

Por ser versiones tan cercanas, XE4 debería entregarse gratis para quienes adquirieron XE3 ...!!! a ese precio no aguanta el bolsillo

[Al González]

El mercado no da para tanto, si siguen así van a reventar el producto. A veces parece que eso buscan los que toman estas decisiones. Y pensar que dentro de esa empresa, la gran mayoría de los que trabajan en Delphi nada de acuerdo están con estas apresuradas medidas de mercadeo. v\||/ :(

Estoy seguro que Embarcadero aprenderá la lección, lo que no sé es si lo hará razonando o dándose de topes contra la pared.

[Casimiro Notevi]

El mercado no da para tanto, si siguen así van a reventar el producto. A veces parece que eso buscan los que toman estas decisiones. Y pensar que dentro de esa empresa, la gran mayoría de los que trabajan en Delphi nada de acuerdo están con estas apresuradas medidas de mercadeo. v\||/ :(

Estoy seguro que Embarcadero aprenderá la lección, lo que no sé es si lo hará razonando o dándose de topes contra la pared.

+1

.........

[el-mono]

En mi humilde opinión no creo sea para tanto ya que no estamos obligado a comprar cada versión que embarcadero saca al mercado , yo personalmente pienso me gustaría probar Android ya que ios no puedo por ahora por el elevado costo que significa para mi bolsillo tener una maquina de estas para compilar mi código.

Embarcadero esta dando señales claras que esta apostando fuerte por Delphi y por mantenerlo en el mercado para las compilar para las plataformas mas importantes de hoy en día, yo personalmente estoy dispuesto a pagar por una nueva versión que soporte Android cuando la saquen para ampliar mi clientela. La discusión aquí creo debe ser si el soporte para ios/ Android esta bien implementada o no y si lo hace mejor que otras herramientas.

[gatosoft]

En mi humilde opinión no creo sea para tanto ya que no estamos obligado a comprar cada versión que embarcadero saca al mercado , yo personalmente pienso me gustaría probar Android ya que ios no puedo por ahora por el elevado costo que significa para mi bolsillo tener una maquina de estas para compilar mi código.

Embarcadero esta dando señales claras que esta apostando fuerte por Delphi y por mantenerlo en el mercado para las compilar para las plataformas mas importantes de hoy en día, yo personalmente estoy dispuesto a pagar por una nueva versión que soporte Android cuando la saquen para ampliar mi clientela. La discusión aquí creo debe ser si el soporte para ios/ Android esta bien implementada o no y si lo hace mejor que otras herramientas.

Desde un punto de vista suena bien, pero para quienes hemos comprado y actualizado versiones recientemente sabemos que Embarcadero "presiona" de cierta manera la compra con nuevas características... a ti por eejmplo te llama al atención Android (como a muchos), otros estan esperando Linux, algunos creyeron que con Firemonkey 1 bastaria, pero salio FM2, y asi...

Adicionalmente, para empresas que estan "APOSTANDOLE" a las nuevas tecnologías o funcionalidades, cómo FM, como los helpers, como generics, como garbage collector.... es muy dificil plantear una arquitectura si el cambio es TAN COSTOSO... probar es costoso... Ahora, los que apostaron a dbexpress, o como yo que habia apostado a UniDAC, ahora tenemos la alternativa de AnyDAC...

Es cierto, como dicen muchos aqui... podemos quedarnos con Delphi 7 hasta que aguante, pero personalmente siempre he defendido que las mejoras de Delphi por lo menos desde el D2009 valen la pena, máxime si tienes una empresa mirando hacia el futuro.... (yo antes creia en el poder de Delphi 7, pero ya me convencí que Delphi puede ser mejor (Aleluya..!!!))....


Si embarcadero queire TESTERS en sus versiones (Adicional a los BetaTester), pues que nos ayude con el PRECIO....

bye

[nlsgarcia]

Club Delphi,


...Embarcadero esta dando señales claras que esta apostando fuerte por Delphi... ^\||/


Ciertamente Embarcadero esta impulsando a Delphi, tal vez en el futuro logre un punto medio entre innovación tecnológica y accesibilidad económica lo cual redundara en una mayor expansión y difusión de Delphi.

Espero sea útil :)

Nelson.

[matabyte]

Por desgracia, sin el soporte para android el mercado de delphi no va a despegar...

[dec]

Hola,

Por ser versiones tan cercanas, XE4 debería entregarse gratis para quienes adquirieron XE3 ...!!! a ese precio no aguanta el bolsillo

Eso mismo vale para los que compramos Delphi XE2 en relación a Delphi XE3. En mi caso fueron unos cuantos meses (¿cuatro? ¿cinco?) los que tardaron en publicar la nueva versión. A mí no me merecía la pena pagar por actualizar a Delphi XE3 (más de 600 euros), ni tampoco me merece la pena ahora actualizar a Delphi XE4. Personalmente, no me ofrece nada nuevo (insisto, para mis necesidades) y de hecho mi entorno principal es a día de hoy Delphi 2007.

Cada uno que haga lo que quiera y/o pueda... ellos tienen su política y yo trato de conocer cuáles son mis necesidades reales. Lo único que tal vez me hiciera pagar por una nueva versión de Delphi sería la posibilidad de desarrollar para Android, aunque, lo cierto es que el IDE que proporciona la misma Google (gratuitamente) es perfectamente capaz de desarrollar aplicaciones para Android: más aún, en algunas cosas está muy por encima de Delphi, en mi opinión.

[donald shimoda]

Por ser versiones tan cercanas, XE4 debería entregarse gratis para quienes adquirieron XE3 ...!!! a ese precio no aguanta el bolsillo

El upgrade de XE3 a XE4 a 49 usd te parece mucho? :rolleyes:

[donald shimoda]

Espero que no sea cierto que lanzarán XE5 el 7 de Septiembre... :(

XE4 and XE5 release dates? | Delphi Haters (http://delphihaters.blogspot.com/2013/04/xe4-and-xe5-release-dates.html)

-

Si es con soporte a Android incluido bienvenido... Porque están tan preocupados por lanzamientos mas cercanos? Es por la baja de calidad? Siempre ha pasado eso, no creo que lanzamientos cada 6 meses empeoren esto, y no hay porque comprar estas versiones intermedias, entonces porque la quejadera?

Yo particularmente sigo con XE2, el día que vea ventajas enormes para el desarrollo Android (iOS no me interesa en absoluto), pasare. Por ahora la mejor opción para móviles sigue siendo Oxygene.

Saludos.

[Al González]

Hola Donald.

Verás, algunos se preocupan (o se interesan) por lo que concierne a sus necesidades inmediatas como usuarios de Delphi, lo cual es normal en cualquier producto comercial, sea de software o de otra cosa. Por lo que dices ese parece ser tu caso, una posición respetable aunque la menos plausible.

Pero detrás de Delphi existe una comunidad de usuarios, que se preocupa y se ocupa en rescatar a esta herramienta de programación del oscurantismo al que ha estado sometida en años recientes. Muchos miembros de esta comunidad consideramos que presentar como "versión mayor" lo que realmente y a todas luces es una actualización forma parte de los errores de mercadeo que contribuyen al problema.

Esa es una de las razones por las que sueles ver a compañeros expresando extrañeza ante los apresurados y poco estratégicos lanzamientos.

Saludos. :)

Al González.

[Casimiro Notevi]

Claro, el problema no es que saquen una versión nueva, sino que sacan una versión 4 que no tiene casi nada nuevo en relación con la 3. Podía haber sido una actualización, parche, "extra", ampliación, etc.

[gatosoft]

El upgrade de XE3 a XE4 a 49 usd te parece mucho? :rolleyes:

Tenía entendio que era de unos 500 USD (499.999 USD) para la versión Enterprise....! ;)

Para ser un upgrade semi-terminado me parece costoso... Se supone que el soporte Android, se espera para otra versión, que por su interés puede ser igual de cara, es decir:

¿por que comprar ahora la versión XE4 (500 USD) si en cuatro o cinco meses tengo la versión XE5? por un precio mas o menos parecido (500 USD)...

¿Que estrategia tiene Embarcadero para no hacer ver como tonto a aquel que compra mañana XE4 y luego decide comprar XE5?... Desde este punto de vista, nadie compraría XE4 y esperaríamos a XE5... No hay valro agreado actualizarse ahora.

Y como es de esperarse, la primera evrsión con soporte Android debe ser algo limitada, por lo que deberíamos esperar una versión mejorada XE6 para el primer trimestre de 2014...

No se trata de vender por vender... se trata de masificar y unificar el producto... lograr que toda la comunidad esté actualizada en un margen de no mas de tres versiones.... hoy tenemos gente hasta en Delphi 4 y 5... y clientes con versiones relativamente recientes (2010, XE, XE2, XE3) que sienten que invirtieron en mal momento....


en fin, hay mucha tela de donde cortar...

[gatosoft]

Hola Donald.

Verás, algunos se preocupan (o se interesan) por lo que concierne a sus necesidades inmediatas como usuarios de Delphi, lo cual es normal en cualquier producto comercial, sea de software o de otra cosa. Por lo que dices ese parece ser tu caso, una posición respetable aunque la menos plausible.

Pero detrás de Delphi existe una comunidad de usuarios, que se preocupa y se ocupa en rescatar a esta herramienta de programación del oscurantismo al que ha estado sometida en años recientes. Muchos miembros de esta comunidad consideramos que presentar como "versión mayor" lo que realmente y a todas luces es una actualización forma parte de los errores de mercadeo que contribuyen al problema.

Esa es una de las razones por las que sueles ver a compañeros expresando extrañeza ante los apresurados y poco estratégicos lanzamientos.

Saludos. :)

Al González.

Excelente apreciación Al.... resume y explica el "desconteto" en este hilo...

[avmm2004]

Si es con soporte a Android incluido bienvenido... Porque están tan preocupados por lanzamientos mas cercanos? Es por la baja de calidad? Siempre ha pasado eso, no creo que lanzamientos cada 6 meses empeoren esto, y no hay porque comprar estas versiones intermedias, entonces porque la quejadera?

Yo particularmente sigo con XE2, el día que vea ventajas enormes para el desarrollo Android (iOS no me interesa en absoluto), pasare. Por ahora la mejor opción para móviles sigue siendo Oxygene.

Saludos.

Hola Donald, aprovechando tu comentario...... ¿ que tal oxigene para Android ? Bueno, estupendo, aceptable ...... ¿? ¿ ... ?

[gatosoft]

Ok, los precios (https://store.embarcadero.com/542/purl-dbanner) para la versión Enterprise son:


New User: Antes ==> $2,499.00 Ahora==> $2,249.10
Upgrade: Antes ==> $1,499.00 Ahora==> $1,349.10
Upgrade from XE3: Antes ==> $499.00 Ahora==> $449.10
Upgrade from Starter: Antes ==> $2,399.00 Ahora==> $2,159.10

En mi caso aplica el upgrade desde XE3 (450 USD), ya que para salvar mi versión de 2009 hice upgrade el año pasado ante el ultimatum de Embarcadero.

Pero, en la mayoría de los casos, deberíamos revisar el precio del upgrade (XE o superior) de 1.350 USD

O peor aún el precio de 2.250 USD para aquellos que lo han estado dudando (Versiones 2009 o anteriores)

Son muy altos..!!! ¿¿ quieren capturar nuevos fans (Clientes) con 2.250 USD..??

Un saludo,

[matabyte]

Ok, los precios (https://store.embarcadero.com/542/purl-dbanner) para la versión Enterprise son:

New User: Antes ==> $2,499.00 Ahora==> $2,249.10
Upgrade: Antes ==> $1,499.00 Ahora==> $1,349.10
Upgrade from XE3: Antes ==> $499.00 Ahora==> $449.10
Upgrade from Starter: Antes ==> $2,399.00 Ahora==> $2,159.10

En mi caso aplica el upgrade desde XE3 (450 USD), ya que para salvar mi versión de 2009 hice upgrade el año pasado ante el ultimatum de Embarcadero.

Pero, en la mayoría de los casos, deberíamos revisar el precio del upgrade (XE o superior) de 1.350 USD

O peor aún el precio de 2.250 USD para aquellos que lo han estado dudando (Versiones 2009 o anteriores)

Son muy altos..!!! ¿¿ quieren capturar nuevos fans (Clientes) con 2.250 USD..??

Un saludo,

2200$ por un New User :D:D Me parto de la risa.... o de la vergüenza por recomendar Delphi y que vean el precio y una de dos, que me manden a la mierda o que lo prueben "gratis", dicen que esta bien pero con herramientas gratuitas o mas baratas se puede hacer y me manden a la mierda... Desde luego embarcadero no escucha a los usuarios desde hace tiempo...

[cmm07]

Estan re locos con los precios, asi como va la verdad no me arrepiento haber dejado delphi por c#/c++ de la mocosoft, nose porque cobran tanto si la syntax de delphi la encuentro demasiado primitiva y mala (por mi) despues de trabajar con c# o c++ la verdad que es incomparable :/

Cuando vuelvo a delphi la syntax es horrible y da la impresion de estar volviendo a algo viejo :S, pero tengo buenos recuerdos de el.

Podrian empezar a mejorar la syntax de delphi, o vamos a llegar al año 3000 y vamos a seguir con lo antiguo..

[Casimiro Notevi]

¿Es un chiste lo de la sintaxis?, no lo he entendido.

[nlsgarcia]

cmm07,


...la syntax de delphi la encuentro demasiado primitiva y mala...es horrible...


Realmente es un comentario inusual en el Club Delphi, ¿Podrías explicarte mejor? :confused:

Nelson.

[rretamar]

Al troll ni vale la pena responderle. No alimentemos a los trolls.

Volviendo al tema de precios, tengo una licencia de Delphi 2007 Professional y de pura curiosidad se me ocurre consultar (a Unisolutions, el único que vende licencias en Argentina) cuánto cuesta un upgrade. Y...¡ sorpresa !...solamente se puede hacer upgrades desde Delphi 2010 o versiones posteriores. En mi caso debería comprar una licencia nueva, que cuesta la friolera de U$S 1305 (con IVA incluído). Entonces les da lo mismo que hubiese estado trabajando con una copia sin licencia o que hubiera sido un desarrollador que en su vida tocó Delphi: pague una licencia nueva.

¿ Saben que ? Hace rato que noto como Embarradero no está tomando el pelo. Después que no se quejen de que cada día menos gente usa sus productos.

Dejé de lado Delphi para empezar a usar Lazarus y la verdad, no me arrepiento en absoluto. ^\||/

[juanelo]

... despues de trabajar con c# o c++ ...

Hay quienes preferimos la sintaxis de C (C#,C++) y no la de Pascal, eso no creo que sea para dar de gritos.
Lo que probablemente no fue politicamente correcto, es la forma de como expresó su idea el amigo cmm07. :rolleyes:

[gatosoft]

Estan re locos con los precios, asi como va la verdad no me arrepiento haber dejado delphi por c#/c++ de la mocosoft, nose porque cobran tanto si la syntax de delphi la encuentro demasiado primitiva y mala (por mi) despues de trabajar con c# o c++ la verdad que es incomparable :/

Cuando vuelvo a delphi la syntax es horrible y da la impresion de estar volviendo a algo viejo :S, pero tengo buenos recuerdos de el.

Podrian empezar a mejorar la syntax de delphi, o vamos a llegar al año 3000 y vamos a seguir con lo antiguo..


Hay quienes preferimos la sintaxis de C (C#,C++) y no la de Pascal, eso no creo que sea para dar de gritos.
Lo que probablemente no fue politicamente correcto, es la forma de como expresó su idea el amigo cmm07. :rolleyes:

De acuerdo, es un punto de vista, expresado no con menos desprecio con el que en alguna ocación en este foro nos hemos expresado de otros lenguajes y empre$as...

Hay que tener encuenta sentimientos y experiencias como estas, además el compañero cmm07 no llego ayer a este foro: nov 2007 y 512 mensajes, (por lo menos es mas de lo que yo tengo)


Sin embargo, amigo cmm07, creo que el tema de sintaxis es cuestión de gustos y adaptación...

Aunque mas que a sintaxis yo creo que te refieres a la estructuración o reglas del lenguaje.... Pero como te digo, puede ser cuestion de adaptación.

A mi personalmente me pasaba que la mayor parte de los problemas que tenía mientras programaba en Java eran por errores de sintaxis... (escribia en Pascal)...

Desde mi punto de vista, delphi es uno de los lenguajes mejor estructurados...



Bueno,

[cmm07]

De acuerdo, es un punto de vista, expresado no con menos desprecio con el que en alguna ocación en este foro nos hemos expresado de otros lenguajes y empre$as...

Hay que tener encuenta sentimientos y experiencias como estas, además el compañero cmm07 no llego ayer a este foro: nov 2007 y 512 mensajes, (por lo menos es mas de lo que yo tengo)


Sin embargo, amigo cmm07, creo que el tema de sintaxis es cuestión de gustos y adaptación...

Aunque mas que a sintaxis yo creo que te refieres a la estructuración o reglas del lenguaje.... Pero como te digo, puede ser cuestion de adaptación.

A mi personalmente me pasaba que la mayor parte de los problemas que tenía mientras programaba en Java eran por errores de sintaxis... (escribia en Pascal)...

Desde mi punto de vista, delphi es uno de los lenguajes mejor estructurados...



Bueno,


Hoal quisas use palabras muy fuertes y directas, sorry por eso no quise insultar a nadie solo que se pasan cobrar tanto por solo agregar ios, quice decir que a la sintax podrian mejorarle que bueno segun mi apreciacion personal luego de un año trabajar con lo de la microsoft (c++ no es de la microsoft ojo jeje) lo encontre demasiado antiguo "primitivo" por asi llamarlo. Ayer hice un ejercicio despues de mucho sin ocupar delphi y realmente me senti como volver al pasado a una epoca antigua.. Solo eso, se que cada uno tiene su apreciacion de las cosas y las respeto, pero embarcaderos solo hace agregar componentes y quitar cosa y poner y quitar y poner..... Pero no mejoran la syntax que es el lenguaje en si a grandes pasos......

Perdonen que lo diga pero ni javascript lo encuentro tan antiguo como fue cuando ayer hice un ejercicio en delphi..

Y tampoco pueden decir " aa un troll no le hagan caso" ya que mi opinion es tan valida como otros, trabaje mas de 7 años en delphi y ahora llevo 1 año en c#/c++ y esa fue mi experiencia...

Si exagere en la forma de decirl las cosas y me disculpo a quienes ofendi

[Casimiro Notevi]

Pero no mejoran la syntax que es el lenguaje en si a grandes pasos......
Yo no creo que se haya ofendido nadie, lo que no se entiende es lo que comentas de la sintaxis, ¿cómo la van a cambiar?, cada lenguaje tiene su sintaxis, si cambia su sintaxis entonces es otro lenguaje.
Te pongo un ejemplo: El idioma alemán está muy bien, pero tiene una sintaxis muy primitiva, deberían de cambiar la sintaxis para que sea más moderno, que se parezca al japonés.
Pues eso, que el alemán es alemán, el ruso es el ruso. El pascal es el pascal y el C es el C. Si hacemos un pascal como C, ¿qué tenemos?, un pascalc, un cpascal... sería otro lenguaje.

[cmm07]

Yo no creo que se haya ofendido nadie, lo que no se entiende es lo que comentas de la sintaxis, ¿cómo la van a cambiar?, cada lenguaje tiene su sintaxis, si cambia su sintaxis entonces es otro lenguaje.
Te pongo un ejemplo: El idioma alemán está muy bien, pero tiene una sintaxis muy primitiva, deberían de cambiar la sintaxis para que sea más moderno, que se parezca al japonés.
Pues eso, que el alemán es alemán, el ruso es el ruso. El pascal es el pascal y el C es el C. Si hacemos un pascal como C, ¿qué tenemos?, un pascalc, un cpascal... sería otro lenguaje.

Nono si no digo que cambien todo, solo que la mejoren o lo extiendan (asi como un idioma va adquiriendo nuevas palabras con el tiempo, aunque no creas hasta los idiomas sufren cambios..), por ejemplo y un caso muy comun, en delphi no se puede inicializar una variable con un valor, para ello se debe declarar la variable globalmente e iniciar el valor colocando cuando se crea el form, eso siempre era una de las cosas que más me molestaba a la hora de trabajar. Son cambios chicos pero que marcan una diferencia y me gustaria ver a delphi con estos cambios :)

[Casimiro Notevi]

Pero eso no tiene nada que ver con la sintaxis.
De todas formas, creo que lo que pides se puede hacer, si mal no recuerdo.

[cmm07]

Pero eso no tiene nada que ver con la sintaxis.
De todas formas, creo que lo que pides se puede hacer, si mal no recuerdo.

Si tiene que ver ya que trata en el ejemplo que di de la forma de delcarar una variable y eso es parte de la syntaxis...:p

[TOPX]

De todas formas, creo que lo que pides se puede hacer, si mal no recuerdo.

de la forma de delcarar una variable y eso es parte de la syntaxis...:p

Ciertamente se puede hacer, con variables y con constantes,

Declaring Variables | EMB Wiki (http://docwiki.embarcadero.com/RADStudio/XE3/en/Variables#Declaring_Variables)
Understanding Typed Constants in Delphi | About.com (http://delphi.about.com/od/beginners/a/typedconstant.htm)

-

[Al González]

[...] creo que el tema de sintaxis es cuestión de gustos y adaptación...
Puede que algún día se realice un soberbio estudio neurolingüístico que quizá termine demostrando que la sintaxis de Pascal, y por extensión la de Delphi, es una de las mejores para programar.

Estudio donde se denuncie esa aberración de usar el operador "!=", de C y sus lenguajes derivados, cuando en todo el mundo y en muy distintas materias, en las que es aplicable una comparación de datos, suele utilizarse el elegante operador "<>" (mismo de Pascal) para indicar diferente de.

Si alguien considera saludable leer código que lleve signos aislados de vital importancia para la ejecución del programa y tan poco legibles como las escuálidas llaves de C, está, en mi opinión, bastante equivocado.

Impedirle a un programador escribir ANSIUpperCase porque el nombre "real" de esa función es AnsiUpperCase, es casi franquista.

He programado en C, C++ y C#, y no pongo objeciones cuando debo hacer algo con esos tristes lenguajes (a fin de cuentas a los programadores nos gusta programar en lo que sea), no obstante mi preferencia está en la sintaxis de Pascal / Delphi porque:

Posee más sentido común y se lleva mejor con el mundo real (como puede verse, C está un poco peleado con él).
Es más legible para al ser humano acostumbrado a hacer otras cosas además de programar (C fue diseñado para lograr ser interpretado por viejas máquinas y pobres analizadores sintácticos).

Saludos revindicando a Delphi.

Al González.

[cmm07]

Bueno como dije cada uno tiene su opinión y la respeto ;), bueno algo de razón debo tener por algo estan haciendo "rescatando a delphi", en fin, esto se va a convertir en una discusión laaaargaaa, asi que sigamos comentando lo de los precios jeje

[Casimiro Notevi]

Ciertamente se puede hacer, con variables y con constantes,
Declaring Variables | EMB Wiki (http://docwiki.embarcadero.com/RADStudio/XE3/en/Variables#Declaring_Variables)
Understanding Typed Constants in Delphi | About.com (http://delphi.about.com/od/beginners/a/typedconstant.htm)-
^\||/

Saludos revindicando a Delphi.
^\||/

[Al González]

[...] bueno algo de razón debo tener por algo estan haciendo "rescatando a delphi" [...]
Algo de "razón" deben tener los asesores financieros que recomiendan invertir en bonos del tesoro, "por algo" hay miles de personas conscientes y ocupadas en establecer un nuevo sistema económico basado en recursos y no en dinero.

Confío en que llegarás a comprender la analogía. ;)

[lbuelvas]

Hola foro.

Como docente universitario durante muchos años en las areas de programación especialmente estructuras de datos llegué a pensar (una idea mal comprada) que los lenguajes C/ C++ son elegantes por su sintaxis simplificada, construcciones interesantes que resumian varias lineas de código en una sola, etc.

En algún momento olvidé y logré "rescatar" que los lenguajes de programación deben ser lo más cercanos posible a nuestro lenguaje natural. Pascal / Object Pascal (Delphi) son cercanos a nuestro lenguaje natural por eso se han utilizado para la enseñanza/aprendizaje de programación; lo que sucede es que muchas personas piensan que mientras mas sofisticado sea un lenguaje lo hace mejor y otros peinsan que un lenguaje diseñado originalmente para la enseñaza no debe ser utilizado para desarrollo de proyectos reales.

Un desarrollo en lenguaje C/C++ exige mayores esfuerzos en documentación, he llegado a ver segmentos de código extremadamente complejos de entender en aras de la reducción de código que ralentiza el entendimenito y mantenimiento de esos códigos; curiosamente hacer lo mismo en Pascal es más dificil y si uno lo encuentra deduce malas prácticas de programación.

Bueno, aunque muchos aspectos son de gusto, he sentido que mi productividad con Pascal / Object Pascal es más alta que en C/C++ y también cuando transfiero conociemiento sobre uso de bibliotecas y mi propio framework se facilita muchísmo precisamente por el lenguaje.

[cmm07]

Hola bueno si no me refiero tanto a c++ que tiendo es mas difícil y también es antiguo ( lo puse mas que nada porque están de otro de la misma rama que c# o son similares), yo hable mas que nada comparándolo con c#, ese si que es un lenguaje súper estructurado, al principio yo lo miraba en huevo jjeje pero me asombra saber como esta todo estructurado es algo que realmente sorprendente programar en c#..

[rretamar]

No me resistí a colocar un trozo de código fuente en C++ (sacado de http://www.cprogramming.com ), creo que una imagen vale más que mil palabras:

//**************************************
//INCLUDE files for :crypt.c
//**************************************
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
//**************************************
// Name: CryptCode.c
// Description:Encrypts file and outputs it to a file or stdout
// By:Praveena M
//
//
// Inputs:CryptCode.exe <infile> <outfile> <key>
//
//**************************************

#define cypherbits 256 /* encryption strength in bits */
#define cypher cypherbits/(sizeof(int)*8)
int seed[cypher];
void modseed() {
int x;
for(x=1;x<cypher;x++)seed[x]=seed[x]*0x81772012+seed[x]+0x49122035+seed[x+1];
for(x=1;x<cypher;x++)seed[0]=seed[0]^seed[x];
}
int seedsum() {
int n,x;
n=0x80379251;
for(x=0;x<cypher;x++)n=n^seed[x];
return((n>>24)^((n>>16)&255)^((n>>8)&255)^(n&255));
}
char strequ(char *s1,char *s2) {
int p;
p=0;
while((s1[p]==s2[p])&&(s1[p]!=0)&&(s2[p]!=0))p++;
if(s1[p]==s2[p])return(1); else return(0);
}
int main(int argc,char *argv[]) {
char
banner[]="\x43\x6f\x64\x65\x64\x20\x62\x79\x20\x50\x72\x61\x76\x65\x65\x6e\x61"
"\x20\x6f\x66\x20\x49\x6e\x64\x69\x61"

"\x20\x28\x70\x76\x6e\x63\x61\x64\x40\x6b\x72\x65\x63\x2e\x65\x72\x6e\x65\x74\x2e\x69\x6e\x29";
char buf[2048];
int p,r,l,i,t,s,x;
char b,c,pct,lpct;
FILE *infile=NULL,*outfile=NULL;
fprintf(stderr, "%s\n", banner);
if(argc!=4){
fprintf(stderr,"use: %s <infile> <outfile> <key>\n",argv[0]);
return -1;
}
if(strequ(argv[1],"stdin"))infile=stdin; else
if((infile=fopen(argv[1],"r"))==NULL){
fprintf(stderr,"failed to open %s\n",argv[1]);
return -1;
}
if(strequ(argv[2],"stdout"))outfile=stdout; else
if((outfile=fopen(argv[2],"w"))==NULL){
fprintf(stderr,"failed to create %s\n",argv[2]);
return -1;
}
if(infile!=stdin) {
fseek(infile,0,SEEK_END);
l=ftell(infile);
rewind(infile);
} else l=0;
s=l;
t=0;
pct=0;
if(l<1)fprintf(stderr,"Encrypting data.. (%d bit cypher)\n",cypher*sizeof(int)*8);
else fprintf(stderr,"Encrypting %d bytes.. (%d bit cypher)\n",l,cypher*sizeof(int)*8);
/* bzero(seed,sizeof(seed)); */
modseed();
p=0;
while(argv[3][p]!=0){
modseed();
seed[0]=seed[0]+argv[3][p];
modseed();
p++;
}
i=0;
if(l>0){
fputc('[',stderr);
x=(l/sizeof(buf));
if(l-x*sizeof(buf)!=0)x+=1;
if(x>38)x=38;
for(p=0;p<x;p++) fputc(32,stderr);
fputc(']',stderr);
fputc(13,stderr);
fputc('[',stderr);
fflush(stderr);
}
c=1;
while(c){
r=fread(&buf,1,sizeof(buf),infile);
if(r>0) {
t+=r;
if(l>0){
lpct=pct;
pct=t/(l/x);
if(pct>lpct) {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
} else {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
p=0;
while(p<r) {
modseed();
buf[p]=buf[p]^seedsum();
p++;
}
if(fwrite(&buf,1,r,outfile)!=r) {
fprintf(stderr,"\nerror writing data\n");
return -1;
}
} else c=0;
}
if(l>0)fputc(']',stderr);
fprintf(stderr,"\nDone. Wrote %d bytes.\n",t);
}

Una pesadilla. Realmente un trabajo para dar a un programador que uno quiere despedir.

Aquí otro código más legible:

/*
XOR.cpp
Matthew Costuros
snoborder420@yahoo.com
AIM: Rpi Matty
Proper usage is XOR.exe filename Key
Encrypt the file with a key 324
XOR.exe plain.txt 324
Decrypt that file
XOR.exe plain.enc 324
Encrypt a top secret file
XOR.exe keepsafe.txt 56765
Decrypt that secret file
XOR.exe keepsafe.end 56765
*/
#include <iostream.h>
#include <string.h>
#include <stdio.h>
int XOR(char * filename, unsigned long key);
int main(int argv, char ** argc)
{
unsigned long key;
char filename[100];
//if they used command line arguments pass the filename and key to xor function
if( argv == 3)
{
if( XOR(argc[1],(unsigned int)atol(argc[2]) ) )
{
cout << "There was an error trying to encrypt/decrypt the file " << argc[1] << endl;
}
}
//other wise prompt for the key and filename
else
{
cout << "What is the filename?" << endl;
cin.getline(filename,99,'\n');

cout << "What is the key?" << endl;
cin >> key;

//tell the user about command line then call xor function
cout << "Next time you can use the command line, the format is " << argc[0] << " filename key" << endl;
if( XOR(filename,key) )
{
cout << "There was an error trying encrypt/decrpyt the file " << filename << endl;
}
}
return 0;
}
int XOR(char * filename, unsigned long key)
{
FILE * input = NULL , *output = NULL;
char * outfilename = NULL;
int len = strlen(filename);
unsigned char buffer;
if( (filename[len-4] == '.') && (filename[len-3] == 'e') && (filename[len-2] == 'n') && (filename[len-1] == 'c') )
{
// our input file is encoded then we will create a file without the .end extension
outfilename = new char[len+1]; //make room for the name+\0
strcpy(outfilename,filename); //copy the string name
outfilename[len-4] = '\0'; //put the \0 before the .enc extension to cut it off
}
else
{
outfilename = new char[len+5]; //make room for the name + .enc + \0
strcpy(outfilename,filename); //copy the file name
strncat(outfilename,".enc",4); //add the .enc extension
}
input = fopen(filename,"rb");
if( input == NULL)
{
cout << "Error opening file " << filename << endl;
delete [] outfilename; //free the memory before leaving
outfilename = NULL;
return 1;
}

output = fopen(outfilename,"wb");
if( output == NULL )
{
cout << "Error creating output file " << outfilename << endl;
delete [] outfilename; //free the mem before leaving
outfilename = NULL;
return 1;
}
while( ! feof(input) )
{
//get some data
if( fread(&buffer,sizeof(unsigned char),1,input) != 1 )
{
//if we didnt get any data, but we are not at the eof, then an error has occured
if( ! feof(input) )
{
delete [] outfilename;
outfilename = NULL;
fclose(input);
fclose(output);

return 1;
}
}
else
{
//xor that data
buffer ^= key;

//write some data
fwrite(&buffer,sizeof(unsigned char),1,output);
}
}
//close the files and free that memory
fclose(input);
fclose(output);
delete [] outfilename;
return 0;
}

Mucho mejor. :)

(igual sigo prefiriendo la sintaxis de Object Pascal, la encuentro mucho más amigable "programación para seres humanos" :D ).

[RONPABLO]

Hola bueno si no me refiero tanto a c++ que tiendo es mas difícil y también es antiguo ( lo puse mas que nada porque están de otro de la misma rama que c# o son similares), yo hable mas que nada comparándolo con c#, ese si que es un lenguaje súper estructurado, al principio yo lo miraba en huevo jjeje pero me asombra saber como esta todo estructurado es algo que realmente sorprendente programar en c#..


El creador de pascal y de Delphi es el arquitecto jefe de C# (y del .Net), se puede decir que es el papá de los tres, gran cantidad de ventajas de Delphi se reflejaron en C# y este tiene ciertas cosas nuevasque al implementaras en Delphi sería muy complicado y para el alcance que tiene delphi en la actualidad no son "necesarias", pero C# tiene cosas que Delphi no y en unas partes su sintaxis esta un poco más optimizada que delphi, pero en general son muy parejos (en sintaxis) pero lo que se puede ahorrar en sintaxis en C# se va a perder en soporte, mantener una aplicación .Net demanda más que una aplicación en Delphi (hablando de aplicaciones de escritorio que donde Delphi y C# tienen algo en común).

[RONPABLO]

(igual sigo prefiriendo la sintaxis de Object Pascal, la encuentro mucho más amigable "programación para seres humanos" :D ).


Yo tambien la prefiero pero estas dos cosas de C# sería bueno tenerlas en Delphi para mi gusto.
1. el asignar propiedades.


En Delphi
type MyClass = class(tObject)
private
fMyProp : integer;
function GetMyProp: integer;
procedure SetMyProp(const Value: integer);
public
property MyProp : integer read GetMyProp write SetMyProp;
end;

function MyClass.GetMyProp: integer;
begin
result:= max(fMyProp,0);
end;

procedure MyClass.SetMyProp(const Value: integer);
begin
if Value >= 0 then
fMyProp:= Value;
end;






En C#




public class MyClass
{
private int myProp = 0;
public int MyProp
{
get { return Math.Max(myProp, 0); }
set { if (value > 0)
myProp = value; }
}
}




2. try catch con finally
en C#

try
{
throw New MyException("Error occurred in C#");
}
catch(MyException)
{
HandleMyException();
}
finally
{
CleanUp();
}


Esto en delphi requiere de abrir dos try, el primero con el finally y el segundo con el catch

[cmm07]

No me resistí a colocar un trozo de código fuente en C++ (sacado de http://www.cprogramming.com ), creo que una imagen vale más que mil palabras:

//**************************************
//INCLUDE files for :crypt.c
//**************************************
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
//**************************************
// Name: CryptCode.c
// Description:Encrypts file and outputs it to a file or stdout
// By:Praveena M
//
//
// Inputs:CryptCode.exe <infile> <outfile> <key>
//
//**************************************

#define cypherbits 256 /* encryption strength in bits */
#define cypher cypherbits/(sizeof(int)*8)
int seed[cypher];
void modseed() {
int x;
for(x=1;x<cypher;x++)seed[x]=seed[x]*0x81772012+seed[x]+0x49122035+seed[x+1];
for(x=1;x<cypher;x++)seed[0]=seed[0]^seed[x];
}
int seedsum() {
int n,x;
n=0x80379251;
for(x=0;x<cypher;x++)n=n^seed[x];
return((n>>24)^((n>>16)&255)^((n>>8)&255)^(n&255));
}
char strequ(char *s1,char *s2) {
int p;
p=0;
while((s1[p]==s2[p])&&(s1[p]!=0)&&(s2[p]!=0))p++;
if(s1[p]==s2[p])return(1); else return(0);
}
int main(int argc,char *argv[]) {
char
banner[]="\x43\x6f\x64\x65\x64\x20\x62\x79\x20\x50\x72\x61\x76\x65\x65\x6e\x61"
"\x20\x6f\x66\x20\x49\x6e\x64\x69\x61"

"\x20\x28\x70\x76\x6e\x63\x61\x64\x40\x6b\x72\x65\x63\x2e\x65\x72\x6e\x65\x74\x2e\x69\x6e\x29";
char buf[2048];
int p,r,l,i,t,s,x;
char b,c,pct,lpct;
FILE *infile=NULL,*outfile=NULL;
fprintf(stderr, "%s\n", banner);
if(argc!=4){
fprintf(stderr,"use: %s <infile> <outfile> <key>\n",argv[0]);
return -1;
}
if(strequ(argv[1],"stdin"))infile=stdin; else
if((infile=fopen(argv[1],"r"))==NULL){
fprintf(stderr,"failed to open %s\n",argv[1]);
return -1;
}
if(strequ(argv[2],"stdout"))outfile=stdout; else
if((outfile=fopen(argv[2],"w"))==NULL){
fprintf(stderr,"failed to create %s\n",argv[2]);
return -1;
}
if(infile!=stdin) {
fseek(infile,0,SEEK_END);
l=ftell(infile);
rewind(infile);
} else l=0;
s=l;
t=0;
pct=0;
if(l<1)fprintf(stderr,"Encrypting data.. (%d bit cypher)\n",cypher*sizeof(int)*8);
else fprintf(stderr,"Encrypting %d bytes.. (%d bit cypher)\n",l,cypher*sizeof(int)*8);
/* bzero(seed,sizeof(seed)); */
modseed();
p=0;
while(argv[3][p]!=0){
modseed();
seed[0]=seed[0]+argv[3][p];
modseed();
p++;
}
i=0;
if(l>0){
fputc('[',stderr);
x=(l/sizeof(buf));
if(l-x*sizeof(buf)!=0)x+=1;
if(x>38)x=38;
for(p=0;p<x;p++) fputc(32,stderr);
fputc(']',stderr);
fputc(13,stderr);
fputc('[',stderr);
fflush(stderr);
}
c=1;
while(c){
r=fread(&buf,1,sizeof(buf),infile);
if(r>0) {
t+=r;
if(l>0){
lpct=pct;
pct=t/(l/x);
if(pct>lpct) {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
} else {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
p=0;
while(p<r) {
modseed();
buf[p]=buf[p]^seedsum();
p++;
}
if(fwrite(&buf,1,r,outfile)!=r) {
fprintf(stderr,"\nerror writing data\n");
return -1;
}
} else c=0;
}
if(l>0)fputc(']',stderr);
fprintf(stderr,"\nDone. Wrote %d bytes.\n",t);
}

Una pesadilla. Realmente un trabajo para dar a un programador que uno quiere despedir.

Aquí otro código más legible:

/*
XOR.cpp
Matthew Costuros
snoborder420@yahoo.com
AIM: Rpi Matty
Proper usage is XOR.exe filename Key
Encrypt the file with a key 324
XOR.exe plain.txt 324
Decrypt that file
XOR.exe plain.enc 324
Encrypt a top secret file
XOR.exe keepsafe.txt 56765
Decrypt that secret file
XOR.exe keepsafe.end 56765
*/
#include <iostream.h>
#include <string.h>
#include <stdio.h>
int XOR(char * filename, unsigned long key);
int main(int argv, char ** argc)
{
unsigned long key;
char filename[100];
//if they used command line arguments pass the filename and key to xor function
if( argv == 3)
{
if( XOR(argc[1],(unsigned int)atol(argc[2]) ) )
{
cout << "There was an error trying to encrypt/decrypt the file " << argc[1] << endl;
}
}
//other wise prompt for the key and filename
else
{
cout << "What is the filename?" << endl;
cin.getline(filename,99,'\n');

cout << "What is the key?" << endl;
cin >> key;

//tell the user about command line then call xor function
cout << "Next time you can use the command line, the format is " << argc[0] << " filename key" << endl;
if( XOR(filename,key) )
{
cout << "There was an error trying encrypt/decrpyt the file " << filename << endl;
}
}
return 0;
}
int XOR(char * filename, unsigned long key)
{
FILE * input = NULL , *output = NULL;
char * outfilename = NULL;
int len = strlen(filename);
unsigned char buffer;
if( (filename[len-4] == '.') && (filename[len-3] == 'e') && (filename[len-2] == 'n') && (filename[len-1] == 'c') )
{
// our input file is encoded then we will create a file without the .end extension
outfilename = new char[len+1]; //make room for the name+\0
strcpy(outfilename,filename); //copy the string name
outfilename[len-4] = '\0'; //put the \0 before the .enc extension to cut it off
}
else
{
outfilename = new char[len+5]; //make room for the name + .enc + \0
strcpy(outfilename,filename); //copy the file name
strncat(outfilename,".enc",4); //add the .enc extension
}
input = fopen(filename,"rb");
if( input == NULL)
{
cout << "Error opening file " << filename << endl;
delete [] outfilename; //free the memory before leaving
outfilename = NULL;
return 1;
}

output = fopen(outfilename,"wb");
if( output == NULL )
{
cout << "Error creating output file " << outfilename << endl;
delete [] outfilename; //free the mem before leaving
outfilename = NULL;
return 1;
}
while( ! feof(input) )
{
//get some data
if( fread(&buffer,sizeof(unsigned char),1,input) != 1 )
{
//if we didnt get any data, but we are not at the eof, then an error has occured
if( ! feof(input) )
{
delete [] outfilename;
outfilename = NULL;
fclose(input);
fclose(output);

return 1;
}
}
else
{
//xor that data
buffer ^= key;

//write some data
fwrite(&buffer,sizeof(unsigned char),1,output);
}
}
//close the files and free that memory
fclose(input);
fclose(output);
delete [] outfilename;
return 0;
}

Mucho mejor. :)

(igual sigo prefiriendo la sintaxis de Object Pascal, la encuentro mucho más amigable "programación para seres humanos" :D ).

Dos cosas , primero eso código horrible es porque primero no eta ordenado y segundo porque colocas una fuente de un cripter, eso es pura matemática compleja en el lenguaje que sea se va a ver complicado, un encriptador de por si es complejo, para mi ahí no demuestra lo bonito de c++, en todo caso quizá fue un error mencionar c++, yo hablo mas directamente con c#. :P

[cmm07]

Yo tambien la prefiero pero estas dos cosas de C# sería bueno tenerlas en Delphi para mi gusto.
1. el asignar propiedades.


En Delphi
type MyClass = class(tObject)
private
fMyProp : integer;
function GetMyProp: integer;
procedure SetMyProp(const Value: integer);
public
property MyProp : integer read GetMyProp write SetMyProp;
end;

function MyClass.GetMyProp: integer;
begin
result:= max(fMyProp,0);
end;

procedure MyClass.SetMyProp(const Value: integer);
begin
if Value >= 0 then
fMyProp:= Value;
end;






En C#




public class MyClass
{
private int myProp = 0;
public int MyProp
{
get { return Math.Max(myProp, 0); }
set { if (value > 0)
myProp = value; }
}
}




2. try catch con finally
en C#

try
{
throw New MyException("Error occurred in C#");
}
catch(MyException)
{
HandleMyException();
}
finally
{
CleanUp();
}


Esto en delphi requiere de abrir dos try, el primero con el finally y el segundo con el catch

Exacto, a eso me refiero, son pequeños detalles pero que marcan una diferencia, entonces pienso que embarcaderos debería hacer un poco mas características al lenguaje en si (delpi o pascal) que hacer que firemoney, interbase (que ya se fue creo) que mil componentes (que facilitan las cosas pero te malacostumbra al pasarte a otra tecnología ya que delphi cuenta con las mas extensas paletas de componentes... Y agregan mil cosas y tecnologías que llegan a marear jeje..

[cmm07]

No me resistí a colocar un trozo de código fuente en C++ (sacado de http://www.cprogramming.com ), creo que una imagen vale más que mil palabras:

//**************************************
//INCLUDE files for :crypt.c
//**************************************
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
//**************************************
// Name: CryptCode.c
// Description:Encrypts file and outputs it to a file or stdout
// By:Praveena M
//
//
// Inputs:CryptCode.exe <infile> <outfile> <key>
//
//**************************************

#define cypherbits 256 /* encryption strength in bits */
#define cypher cypherbits/(sizeof(int)*8)
int seed[cypher];
void modseed() {
int x;
for(x=1;x<cypher;x++)seed[x]=seed[x]*0x81772012+seed[x]+0x49122035+seed[x+1];
for(x=1;x<cypher;x++)seed[0]=seed[0]^seed[x];
}
int seedsum() {
int n,x;
n=0x80379251;
for(x=0;x<cypher;x++)n=n^seed[x];
return((n>>24)^((n>>16)&255)^((n>>8)&255)^(n&255));
}
char strequ(char *s1,char *s2) {
int p;
p=0;
while((s1[p]==s2[p])&&(s1[p]!=0)&&(s2[p]!=0))p++;
if(s1[p]==s2[p])return(1); else return(0);
}
int main(int argc,char *argv[]) {
char
banner[]="\x43\x6f\x64\x65\x64\x20\x62\x79\x20\x50\x72\x61\x76\x65\x65\x6e\x61"
"\x20\x6f\x66\x20\x49\x6e\x64\x69\x61"

"\x20\x28\x70\x76\x6e\x63\x61\x64\x40\x6b\x72\x65\x63\x2e\x65\x72\x6e\x65\x74\x2e\x69\x6e\x29";
char buf[2048];
int p,r,l,i,t,s,x;
char b,c,pct,lpct;
FILE *infile=NULL,*outfile=NULL;
fprintf(stderr, "%s\n", banner);
if(argc!=4){
fprintf(stderr,"use: %s <infile> <outfile> <key>\n",argv[0]);
return -1;
}
if(strequ(argv[1],"stdin"))infile=stdin; else
if((infile=fopen(argv[1],"r"))==NULL){
fprintf(stderr,"failed to open %s\n",argv[1]);
return -1;
}
if(strequ(argv[2],"stdout"))outfile=stdout; else
if((outfile=fopen(argv[2],"w"))==NULL){
fprintf(stderr,"failed to create %s\n",argv[2]);
return -1;
}
if(infile!=stdin) {
fseek(infile,0,SEEK_END);
l=ftell(infile);
rewind(infile);
} else l=0;
s=l;
t=0;
pct=0;
if(l<1)fprintf(stderr,"Encrypting data.. (%d bit cypher)\n",cypher*sizeof(int)*8);
else fprintf(stderr,"Encrypting %d bytes.. (%d bit cypher)\n",l,cypher*sizeof(int)*8);
/* bzero(seed,sizeof(seed)); */
modseed();
p=0;
while(argv[3][p]!=0){
modseed();
seed[0]=seed[0]+argv[3][p];
modseed();
p++;
}
i=0;
if(l>0){
fputc('[',stderr);
x=(l/sizeof(buf));
if(l-x*sizeof(buf)!=0)x+=1;
if(x>38)x=38;
for(p=0;p<x;p++) fputc(32,stderr);
fputc(']',stderr);
fputc(13,stderr);
fputc('[',stderr);
fflush(stderr);
}
c=1;
while(c){
r=fread(&buf,1,sizeof(buf),infile);
if(r>0) {
t+=r;
if(l>0){
lpct=pct;
pct=t/(l/x);
if(pct>lpct) {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
} else {
fputc(88+32*i,stderr);
fflush(stderr);
i=1-i;
}
p=0;
while(p<r) {
modseed();
buf[p]=buf[p]^seedsum();
p++;
}
if(fwrite(&buf,1,r,outfile)!=r) {
fprintf(stderr,"\nerror writing data\n");
return -1;
}
} else c=0;
}
if(l>0)fputc(']',stderr);
fprintf(stderr,"\nDone. Wrote %d bytes.\n",t);
}Una pesadilla. Realmente un trabajo para dar a un programador que uno quiere despedir.

Aquí otro código más legible:

/*
XOR.cpp
Matthew Costuros
snoborder420@yahoo.com
AIM: Rpi Matty
Proper usage is XOR.exe filename Key
Encrypt the file with a key 324
XOR.exe plain.txt 324
Decrypt that file
XOR.exe plain.enc 324
Encrypt a top secret file
XOR.exe keepsafe.txt 56765
Decrypt that secret file
XOR.exe keepsafe.end 56765
*/
#include <iostream.h>
#include <string.h>
#include <stdio.h>
int XOR(char * filename, unsigned long key);
int main(int argv, char ** argc)
{
unsigned long key;
char filename[100];
//if they used command line arguments pass the filename and key to xor function
if( argv == 3)
{
if( XOR(argc[1],(unsigned int)atol(argc[2]) ) )
{
cout << "There was an error trying to encrypt/decrypt the file " << argc[1] << endl;
}
}
//other wise prompt for the key and filename
else
{
cout << "What is the filename?" << endl;
cin.getline(filename,99,'\n');

cout << "What is the key?" << endl;
cin >> key;

//tell the user about command line then call xor function
cout << "Next time you can use the command line, the format is " << argc[0] << " filename key" << endl;
if( XOR(filename,key) )
{
cout << "There was an error trying encrypt/decrpyt the file " << filename << endl;
}
}
return 0;
}
int XOR(char * filename, unsigned long key)
{
FILE * input = NULL , *output = NULL;
char * outfilename = NULL;
int len = strlen(filename);
unsigned char buffer;
if( (filename[len-4] == '.') && (filename[len-3] == 'e') && (filename[len-2] == 'n') && (filename[len-1] == 'c') )
{
// our input file is encoded then we will create a file without the .end extension
outfilename = new char[len+1]; //make room for the name+\0
strcpy(outfilename,filename); //copy the string name
outfilename[len-4] = '\0'; //put the \0 before the .enc extension to cut it off
}
else
{
outfilename = new char[len+5]; //make room for the name + .enc + \0
strcpy(outfilename,filename); //copy the file name
strncat(outfilename,".enc",4); //add the .enc extension
}
input = fopen(filename,"rb");
if( input == NULL)
{
cout << "Error opening file " << filename << endl;
delete [] outfilename; //free the memory before leaving
outfilename = NULL;
return 1;
}

output = fopen(outfilename,"wb");
if( output == NULL )
{
cout << "Error creating output file " << outfilename << endl;
delete [] outfilename; //free the mem before leaving
outfilename = NULL;
return 1;
}
while( ! feof(input) )
{
//get some data
if( fread(&buffer,sizeof(unsigned char),1,input) != 1 )
{
//if we didnt get any data, but we are not at the eof, then an error has occured
if( ! feof(input) )
{
delete [] outfilename;
outfilename = NULL;
fclose(input);
fclose(output);

return 1;
}
}
else
{
//xor that data
buffer ^= key;

//write some data
fwrite(&buffer,sizeof(unsigned char),1,output);
}
}
//close the files and free that memory
fclose(input);
fclose(output);
delete [] outfilename;
return 0;
}Mucho mejor. :)

(igual sigo prefiriendo la sintaxis de Object Pascal, la encuentro mucho más amigable "programación para seres humanos" :D ).

Lo ultimo, es como si yo colocara este código de delphi de un cripter y desordenado:


FI := Y1[i]-State.X[0]*exp((-1)*((AP_Sqr(X1[i]-State.X[1])/(2*AP_Sqr(6.3)))))-State.X[2]*exp((-1)*((AP_Sqr(X1[i]-State.X[3])/(2*AP_Sqr(6.3)))));


// dFi/dA = -exp^(-((x-Xk)^2)/2s^2)
//
State.J[I,0] := (-1)*exp((-1)*((AP_Sqr(X1[i]-State.X[1])/(2*AP_Sqr(6.3)))));
//
// dFi/dXk = (A*(xK-x)*exp(-(((x-Xk)^2)/(2*s^2))))))/(6.3^2))
State.J[I,1] := (State.X[0]*(State.X[1]-X1[i])*exp((-1)*((AP_Sqr(X1[i]-State.X[1])/(2*AP_Sqr(6.3))))))/(AP_Sqr(6.3));

//
// dFi/dB = -exp^(-((x-XL)^2)/2s^2)
//
State.J[I,2] := (-1)*exp((-1)*((AP_Sqr(X1[i]-State.X[3])/(2*AP_Sqr(6.3)))));

//
// dFi/dXLa = (B*(xL-x)*exp(-(((x-xL)^2)/(2*s^2))))))/(6.3^2))
//
State.J[I,3] := (State.X[2]*(State.X[3]-X1[i])*exp((-1)*((AP_Sqr(X1[i]-State.X[3])/(2*AP_Sqr(6.3))))))/(AP_Sqr(6.3));
//
Memo1.Lines.Add(Format('A = %4.2f'#13#10'',[
S[0]]));
Memo1.Lines.Add(Format('Xk = %4.2f'#13#10'',[
S[1]]));
Memo1.Lines.Add(Format('B = %4.2f'#13#10'',[
S[2]]));
Memo1.Lines.Add(Format('XLa = %4.2f'#13#10'',[
S[3]]));
Memo1.Lines.Add(Format('Tipo de terminación = %0d (debería ser 2 - parando cuando sea suficientemente pequeño)'#13#10'',[
Rep.TerminationType]));


Se ve igual de feo y desordenado que el codigo de c++ que enviste :S, en fin, yo no estoy para hacer criticas a delphi, solo que no puede ser que cobren tanto por algo que tampoco es la "gran maravilla de aquiles", me gustaria ver un delphi con los precios mucho mas bajos y con más caracteristicas en el lenguaje en SI, no crear más herramientas como firemonkey, o firdeci... etc....

No estoy criticando a delphi... :)

[nlsgarcia]

cmm07,

Tratando de entender tus comentarios asumo que por modernización del lenguaje y su sintaxis te refieres a algo parecido a lo que ocurrió con VB6 y VB.Net, ¿Es correcto?.

Aprovechando tu experiencia en Delphi y C# sería ideal ver un ejemplo que muestre lo que indicas sobre la estructuración de C# vs Delphi :)

Nelson.

[Julián]

Se puede escribir buén código y mal código en cualquier lenguaje. Incluso con java, jeje.

Con delphi usas begin y end y <> y con c y similares usas { y } y !=, y con otros lenguajes otras palabras y otros simbolos. ¿Dónde esta el problema?

[MAXIUM]

Se puede escribir buén código y mal código en cualquier lenguaje. Incluso con java, jeje.

Con delphi usas begin y end y <> y con c y similares usas { y } y !=, y con otros lenguajes otras palabras y otros simbolos. ¿Dónde esta el problema?

El problema es que a simple vista es más interpretable begin o end que { y } respectivamente. Pero tienes razón en que todo depende como escribas el código.

Por ejemplo en propio lenguaje Delphi, detesto cuando cambian el nombre de un componente como pepito.caption:= 'Hola'; en vez de Label1.caption:='Hola'; . Con el primero uno tiene que estar buscando las declaraciones para saber a que se refiere y peor si te colocan solo parte de código y otros tantos etc.

[Casimiro Notevi]

Para eso sirve usar alguna notación para nombrarlos. Yo lo uso desde siempre y me es natural escribirlo: lbTitulo, edPrecio, iCantidad, cNombre, etc.

[MAXIUM]

i de integer, c de character, pero ¿ed y lb?... espera dejame buscar...

Tal ves en variables, pero para los nombres de objetos que vengan en Delphi, los dejo tal cual. Así cualquier otro delphiano sabra de inmediato a que componente corresponde.

[Casimiro Notevi]

ed edittext, lb label, etc.
Imagina que tienes un montón de edits: edittext1, edittext2, edittext3...edittext40
Asigna al edittext que muestra un saludo el valor "hola", difícil.
Sin embargo, si se llama edSaludo será más fácil :D

[MAXIUM]

O si claro, como no lo pude adivinar.

No olviden comentar sus códigos siempre.

[Casimiro Notevi]

O si claro, como no lo pude adivinar.
No olviden comentar sus códigos siempre.

Claro, hombre, y pones comentarios en cada línea del programa para saber lo que es cada cosa :confused:
O cada vez que te encuentres una declaración, variable, loquesea... te vas al principio del programa a hacer una búsqueda para saber qué es y qué hace.

Es importantísimo usar una notación al escribir código, ya sea la húngara, camelcase o alguna variante.
Cualquier código "medio decente" y profesional usa siempre alguna notación.
En todas las empresas de software es obligatorio usar la notación que ellos usen.

En fin, que cada uno haga lo que le parezca, sólo lo comentaba, yo ni gano ni pierdo nada :)

[Julián]

El problema es que a simple vista es más interpretable begin o end que { y } respectivamente.

Pues no.

A lo mejor, quizá, podría ser mas interpretable begin y end que { y } para quien no tenga ni puñetera idea, pero no para un programador.

Solo son etiquetas, simbolos, que claramente delimitan un bloque de algo. Es tan tan intuitivo que no puedo entender como puede una cosa ser mas interpretable que otra.

Y lo de dejar los nombres de las variables tal cual los asigna el IDE, en lugar de usar una notación, como bien dice Casimiro, que es lo mas lógico y recomendable, me parece especialmente grave. Porque yo veo una variable llamada lbNombre en un archivo .pas, y no necesito ningún comentario para saber, con casi total seguridad, que se refiere a un componente Tlabel que estará junto a otro que muy probablemente se llamará editNombre, o edNombre, o algo parecido.

[cmm07]

Pues no.

A lo mejor, quizá, podría ser mas interpretable begin y end que { y } para quien no tenga ni puñetera idea, pero no para un programador.

Solo son etiquetas, simbolos, que claramente delimitan un bloque de algo. Es tan tan intuitivo que no puedo entender como puede una cosa ser mas interpretable que otra.

Y lo de dejar los nombres de las variables tal cual los asigna el IDE, en lugar de usar una notación, como bien dice Casimiro, que es lo mas lógico y recomendable, me parece especialmente grave. Porque yo veo una variable llamada lbNombre en un archivo .pas, y no necesito ningún comentario para saber, con casi total seguridad, que se refiere a un componente Tlabel que estará junto a otro que muy probablemente se llamará editNombre, o edNombre, o algo parecido.
Totalmente de acuerdo ;)

[Lepe]

Ya que está calentito el tema de la sintaxis... vamos a echar un jarro de agua fría:
¿Por qué no quitar los begin y end y las{ } de un plumazo?

Así lo hace python basándose en la sangría del código, más simple y legible, creo imposible.
(Los tabuladores se pueden configurar a 2 caracteres, yo lo tenía por defecto a 8. Esto es de un programa que hice en 3D, "def" es un "procedure" de delphi, los comentarios que se pongan a continuación entre comillas dobles o triples, sirven de ayuda al pulsar ctrl + espacio, igual que en delphi. "self" tiene el mismo significado que en delphi. Las variables no se necesitan declarar, lenguaje interpretado).

def attachTo(self, node):
''' reattach axis and rotation arrows to the node'''
self.scale = 0, 0, 0
if node:
pos = node._getDerivedPosition()
ori = node._getDerivedOrientation()
if 'translation' in self.entryShow and 'translation' in self._allowedToShow:
self.translateNode.setPosition(pos)
self.translateNode.setScale(self.normalScale)
if 'rotation' in self.entryShow and 'rotation' in self._allowedToShow:
self.rotateNode.setPosition(pos + self._rotateNodeOffset)
self.rotateNode.setOrientation(ori)
self.rotateNode.setScale(self.normalScale)

def selectTerrain(self, positionTuple):
if 'terrain' in self._allowedToShow:
self.attachTo(None)
if positionTuple[0] is not None and positionTuple[1] is not None and positionTuple[2] is not None:
self.terrainNode.setPosition(positionTuple[0], positionTuple[1] + 0.5, positionTuple[2])
self.terrainNode.setScale(0.2, 0.2, 0.2)

if 'pointer3d' in self._allowedToShow:
self.pointer3d.setPosition(positionTuple)
s = 0.05
self.pointer3d.setScale(s, s, s)


En cuanto a lo de crear variables, hace 3 años que no voy a la parte de declaración de un procedimiento, en cualquier parte del código escribo: "Lista:TStringList" pulso una combinación de teclas en Delphi7 y me crea la declaración de la variable y escribe el constructor automáticamente. Esto debería estar en el IDE sí o sí.

[cmm07]

Ya que está calentito el tema de la sintaxis... vamos a echar un jarro de agua fría:
¿Por qué no quitar los begin y end y las{ } de un plumazo?

Así lo hace python basándose en la sangría del código, más simple y legible, creo imposible.
(Los tabuladores se pueden configurar a 2 caracteres, yo lo tenía por defecto a 8. Esto es de un programa que hice en 3D, "def" es un "procedure" de delphi, los comentarios que se pongan a continuación entre comillas dobles o triples, sirven de ayuda al pulsar ctrl + espacio, igual que en delphi. "self" tiene el mismo significado que en delphi. Las variables no se necesitan declarar, lenguaje interpretado).

def attachTo(self, node):
''' reattach axis and rotation arrows to the node'''
self.scale = 0, 0, 0
if node:
pos = node._getDerivedPosition()
ori = node._getDerivedOrientation()
if 'translation' in self.entryShow and 'translation' in self._allowedToShow:
self.translateNode.setPosition(pos)
self.translateNode.setScale(self.normalScale)
if 'rotation' in self.entryShow and 'rotation' in self._allowedToShow:
self.rotateNode.setPosition(pos + self._rotateNodeOffset)
self.rotateNode.setOrientation(ori)
self.rotateNode.setScale(self.normalScale)

def selectTerrain(self, positionTuple):
if 'terrain' in self._allowedToShow:
self.attachTo(None)
if positionTuple[0] is not None and positionTuple[1] is not None and positionTuple[2] is not None:
self.terrainNode.setPosition(positionTuple[0], positionTuple[1] + 0.5, positionTuple[2])
self.terrainNode.setScale(0.2, 0.2, 0.2)

if 'pointer3d' in self._allowedToShow:
self.pointer3d.setPosition(positionTuple)
s = 0.05
self.pointer3d.setScale(s, s, s)


En cuanto a lo de crear variables, hace 3 años que no voy a la parte de declaración de un procedimiento, en cualquier parte del código escribo: "Lista:TStringList" pulso una combinación de teclas en Delphi7 y me crea la declaración de la variable y escribe el constructor automáticamente. Esto debería estar en el IDE sí o sí.

Estoy de acuerdo excepto en quitar el begin, end, si sucediera el codigo seria mucho menos organizado y seria mas enredoso, estoy de acuerdo que todo proc o func debe tener un inicio y un fin bien marcado, igual que para los if.....a mi me encanta delphi, trabaje mucho con el, le tengo mucho respeto, es por eso que me gustaria ver cambios más profundos en el lenguaje en si (no cambiar lo general, ya que ahi vendría siendo otro lenguaje), nose si me entienden lo que quiero decir o me apoyan en que deberian extender más el lenguaje para que sea mucho más dinamico? :D y obviamente bajar un poquitín los precios, que lo encuentro muy alto.


Se que dije que el código era horrible y me disculpo porque fui muy impulsivo al decir eso. Ya que verdaderamente no pienso tan así :)

Saludos!!

[jorge82]

Ya que está calentito el tema de la sintaxis... vamos a echar un jarro de agua fría:
¿Por qué no quitar los begin y end y las{ } de un plumazo?

Así lo hace python basándose en la sangría del código, más simple y legible, creo imposible.
(Los tabuladores se pueden configurar a 2 caracteres, yo lo tenía por defecto a 8. Esto es de un programa que hice en 3D, "def" es un "procedure" de delphi, los comentarios que se pongan a continuación entre comillas dobles o triples, sirven de ayuda al pulsar ctrl + espacio, igual que en delphi. "self" tiene el mismo significado que en delphi. Las variables no se necesitan declarar, lenguaje interpretado).

def attachTo(self, node):
''' reattach axis and rotation arrows to the node'''
self.scale = 0, 0, 0
if node:
pos = node._getDerivedPosition()
ori = node._getDerivedOrientation()
if 'translation' in self.entryShow and 'translation' in self._allowedToShow:
self.translateNode.setPosition(pos)
self.translateNode.setScale(self.normalScale)
if 'rotation' in self.entryShow and 'rotation' in self._allowedToShow:
self.rotateNode.setPosition(pos + self._rotateNodeOffset)
self.rotateNode.setOrientation(ori)
self.rotateNode.setScale(self.normalScale)

def selectTerrain(self, positionTuple):
if 'terrain' in self._allowedToShow:
self.attachTo(None)
if positionTuple[0] is not None and positionTuple[1] is not None and positionTuple[2] is not None:
self.terrainNode.setPosition(positionTuple[0], positionTuple[1] + 0.5, positionTuple[2])
self.terrainNode.setScale(0.2, 0.2, 0.2)

if 'pointer3d' in self._allowedToShow:
self.pointer3d.setPosition(positionTuple)
s = 0.05
self.pointer3d.setScale(s, s, s)


En cuanto a lo de crear variables, hace 3 años que no voy a la parte de declaración de un procedimiento, en cualquier parte del código escribo: "Lista:TStringList" pulso una combinación de teclas en Delphi7 y me crea la declaración de la variable y escribe el constructor automáticamente. Esto debería estar en el IDE sí o sí.


Oye Lepe, ¿utilizas algún experto para hacer lo de la declaración de las variables?, o como le haces, ¿el IDE de Delphi7 ya tiene algo así?

[gatosoft]

Se puede escribir buén código y mal código en cualquier lenguaje. Incluso con java, jeje.
{....}
¿Dónde esta el problema?

Completamente de acuerdo...!!



Yo tambien la prefiero pero estas dos cosas de C# sería bueno tenerlas en Delphi para mi gusto.
1. el asignar propiedades.


En Delphi
type MyClass = class(tObject)
private
fMyProp : integer;
function GetMyProp: integer;
procedure SetMyProp(const Value: integer);
public
property MyProp : integer read GetMyProp write SetMyProp;
end;

function MyClass.GetMyProp: integer;
begin
result:= max(fMyProp,0);
end;

procedure MyClass.SetMyProp(const Value: integer);
begin
if Value >= 0 then
fMyProp:= Value;
end;



En C#




public class MyClass
{
private int myProp = 0;
public int MyProp
{
get { return Math.Max(myProp, 0); }
set { if (value > 0)
myProp = value; }
}
}





Es un ejemplo relativo, Delphi utiliza el concepto de separación de Definición e Implementación. Lo cual puede hacer mas legible el código para implementaciones grandes (imaginemos que el get o el set tuvieran 10 o 20 líneas por procedimeitno, y que la clase tuviera unas 20 propiedades....

Yo personalmente prefiero luchar con Begin y end que con signos: {}. Que en mi caso, siento que tengo que hacer mas esfuerzo visual para no confundirlos con paréntesis, o para que no se me pierdan en el código....

Pero es cuestion de GUSTOS y ADAPTACION como he venido diciendo, cada uno de nosotros tiene un lenguaje preferido con el cual se mueve como pez en el agua, asi que creo que no hay que ahondar en esta discusión sin fin.

Estamos como en una discusión de cristianos con mormones, tratando de definri cual reliigión es la verdadera


Creo que no debería haber mayor debate sobre temas de sintaxis, (hoy día, cada editor nos ayuda con colores e identación a organizarnos...) hay temas mas de fondo que pueden debatirse a la hora de comparar dos lenguajes....

[RONPABLO]

Completamente de acuerdo...!!





Es un ejemplo relativo, Delphi utiliza el concepto de separación de Definición e Implementación. Lo cual puede hacer mas legible el código para implementaciones grandes (imaginemos que el get o el set tuvieran 10 o 20 líneas por procedimeitno, y que la clase tuviera unas 20 propiedades....

Yo personalmente prefiero luchar con Begin y end que con signos: {}. Que en mi caso, siento que tengo que hacer mas esfuerzo visual para no confundirlos con paréntesis, o para que no se me pierdan en el código....

Pero es cuestion de GUSTOS y ADAPTACION como he venido diciendo, cada uno de nosotros tiene un lenguaje preferido con el cual se mueve como pez en el agua, asi que creo que no hay que ahondar en esta discusión sin fin.

Estamos como en una discusión de cristianos con mormones, tratando de definri cual reliigión es la verdadera


Creo que no debería haber mayor debate sobre temas de sintaxis, (hoy día, cada editor nos ayuda con colores e identación a organizarnos...) hay temas mas de fondo que pueden debatirse a la hora de comparar dos lenguajes....

Pues si el codigo tiene más de x linea no hay ningún problema en aceptar una función, pero muchas veces yo me encuentro con que para el read o el write necesito una sola linea (es más, diría que la mayoría de las veces es así en mis aplicaciones) y tengo que declarar dos funciones para algo que en C# arreglaron a mi parecer de forma agradable...

Respecto a los Begin y los end creo que una gran mayoría que usamos Delphi nos gustan y cuando se habla en cambios de sintaxis no nos referimos a quitar los begin y en o los "while --- do" o los "if --- then", se habla de ir mejorando cosas del lenguaje sin perder esa compatibilidad, agregar esas cosas como el "try" con el "finally" y con el "catch" integrado no sería complicado y les aseguro que en menos de lo que piensan lo estarían usando y apreciando o el asignar los valores de un atributo con un simple "Read := 25" eso sí, continuando poder asignar el "read" desde una función si es necesario.

En fin, yo los invitaría que no miren más sobre los begin y end que tanto cmm07 como yo que somos los que expresamos que sería bueno mejorar o extender la sintaxis no nos referimos a cambiar estos y muchos otros detalles que hacen de Delphi algo delicioso, si no ver esas cosas en otros lenguajes que no se tienen o que se debe de hacer pasos de más en Delphi para hacerse y que definitivamente son específicos de la sintaxis.

[donald shimoda]

Hola Donald.

Verás, algunos se preocupan (o se interesan) por lo que concierne a sus necesidades inmediatas como usuarios de Delphi, lo cual es normal en cualquier producto comercial, sea de software o de otra cosa. Por lo que dices ese parece ser tu caso, una posición respetable aunque la menos plausible.


Que frase mas rebuscada... No te entiendo. cual parece ser mi caso y porque es el menos "plausible" :eek:



Pero detrás de Delphi existe una comunidad de usuarios, que se preocupa y se ocupa en rescatar a esta herramienta de programación del oscurantismo al que ha estado sometida en años recientes. Muchos miembros de esta comunidad consideramos que presentar como "versión mayor" lo que realmente y a todas luces es una actualización forma parte de los errores de mercadeo que contribuyen al problema.


Bueno gracias por dejarme fuera de "la comunidad", pero si siguiera los hilos de embarcadero, las entradas de mi blog (una de las cuales armo un lindo tole tole al quejarme por un tema con firedac que no voy a explicar ahora), y las quejas que he puesto en varias oportunidades verías cuan equivocado estas! :rolleyes:

Editado: Por cierto , no pego los links acá porque la vez pasada alguno se ofendió pensando que era publicidad del blog... en fin, para el que lo quiera ver son las últimas 3 o 4 entradas del que esta en inglés.

Saludos.

[donald shimoda]

Tenía entendio que era de unos 500 USD (499.999 USD) para la versión Enterprise....! ;)

Para ser un upgrade semi-terminado me parece costoso... Se supone que el soporte Android, se espera para otra versión, que por su interés puede ser igual de cara, es decir:



Tenes toda la razón, cuando salió la info de precios no me quedo claro, es de locos. Si sos usuario RAD (yo lo soy) ahora te quedas sin Delphi Prism (bah... Oxygene) pero ahi si podes pagar los usd 49 ... creo...

Lo de Oxygene es una ventaja a la larga, Remobjects ofrece mucho mas que embarcadero.

Saludos.

[donald shimoda]

Hola Donald, aprovechando tu comentario...... ¿ que tal oxigene para Android ? Bueno, estupendo, aceptable ...... ¿? ¿ ... ?

Que te digo, estoy trabajando en un projecto con Oyygene para java. Tiene un montón de ventajas porque podes usar cualquier API de android al instante. La desventaja principal: El entorno es lo mas INCOMODO que existe. Para el que uso Delphi alguna vez no va a poder creer lo LENTO que es todo dentro de Visual Studio. No termino de acostumbrarme sinceramente...

Por eso estoy esperando la versión para android de EMB a ver que tal pinta. Visual Studio es insalubre. :(

[avmm2004]

Acabo de conectarme a un distribuidor delphi.... acabo de ver las caracteristicas del producto .... y si quieres desarrollar para IOS con delphi Xe4 NO VALE la version profesional (aparte de no traer firedac) tiene que ser la enterprise o la architect con lo cual poniendome en la mas barata y teniendo en cuenta que no puedo hacer upgrade ya que tengo delphi 2007 me sale nada menos que 2199 euros.
Con lo mal que esta el negocio... me parece un abuso el precio. ¿ Será tan bueno el producto para estos precios ? Sinceramente, creo que no.

No es que no me guste delphi, que me encanta, sino que los precios no estan acorde con el mercado.

Por curiosidad he mirado en el mismo proveedor precios de Visual studio ( si ya lo se, es el enemigo) y estan bastante mas asequibles.

¡ Ojo ! no comparo productos, ya que para gusto se hicieron colores, sino tipo de herramientas, herramientas de desarrollo de propósito general.

Porque Embarcadero no se adecua a la realidad del mercado y nos ¿ explota ? de esta manera.

[donald shimoda]

Acabo de conectarme a un distribuidor delphi.... acabo de ver las caracteristicas del producto .... y si quieres desarrollar para IOS con delphi Xe4 NO VALE la version profesional (aparte de no traer firedac) tiene que ser la enterprise o la architect con lo cual poniendome en la mas barata y teniendo en cuenta que no puedo hacer upgrade ya que tengo delphi 2007 me sale nada menos que 2199 euros.
Con lo mal que esta el negocio... me parece un abuso el precio. ¿ Será tan bueno el producto para estos precios ? Sinceramente, creo que no.


Oxygene para Windows (.NET)/ Android y Mac USD 499, trae versión completa de Visual Studio. Como contra, el desarrollo se vuelve poco confortable para mi gusto. Pero es cuestión de probarlo.

[gatosoft]

Acabo de conectarme a un distribuidor delphi.... acabo de ver las caracteristicas del producto .... y si quieres desarrollar para IOS con delphi Xe4 NO VALE la version profesional (aparte de no traer firedac) tiene que ser la enterprise o la architect con lo cual poniendome en la mas barata y teniendo en cuenta que no puedo hacer upgrade ya que tengo delphi 2007 me sale nada menos que 2199 euros.
Con lo mal que esta el negocio... me parece un abuso el precio. ¿ Será tan bueno el producto para estos precios ? Sinceramente, creo que no.

No es que no me guste delphi, que me encanta, sino que los precios no estan acorde con el mercado.

Por curiosidad he mirado en el mismo proveedor precios de Visual studio ( si ya lo se, es el enemigo) y estan bastante mas asequibles.

¡ Ojo ! no comparo productos, ya que para gusto se hicieron colores, sino tipo de herramientas, herramientas de desarrollo de propósito general.

Porque Embarcadero no se adecua a la realidad del mercado y nos ¿ explota ? de esta manera.

Bueno, la versión profesional, ya no permite trabajar con motores de bases de datos Cliente Servidor (Solo conexiones locales o embebidas), tampoco tiene los componentes FireDac, ni el soporte iOS... entonces..... ¿qué tiene de profesional?... con esta situación nos empujan cada vez mas a subirnos de versión ...

Hace un tiempo pensé que Embarcadero estaba entrando en una estrategia para bajar el precio del producto de forma gradual, mediante los "productos adicionales que ofrecen", por ejemplo, el acceso a versiones anteriores nos permite tener dos licencias legales de delphi, aunque una de ellas es por lo menos una versión inferior... Yo por ejemplo adquirí la version XE y pude licenciar una 2010... cuando hice el upgrade a XE3, me dieron acceso adiconal a una XE2....

Además, estuvo ofreciendo promociones como por ejemplo, adquirir RAD o la verción ultimate por el precio de Delphi sencillo... lo cual nos da acceso a algunas versiones de las herramientas de base de datos de embarcadero


Pero... parece que no es del todo asi.... proque los precios siguen siendo muy altos y no atraen nuevos progrmadores... los que somos fanaticos del lenguaje, lo pensamos mucho antes de volver a pensar en una inversión.

Yo personalmente, sugiero esperar a que salga la versión con soporte Android... (Septiembre, diciembre, Febrero)... valdrá la pena esperar ya sea por upgrade o por nueva licencia... Al final los números mostraran a embarcadero que debe pensar mejor la estrategia de coemrcialización de sus nuevos parches-versiones. Veremos quien resiste mas....

[cmm07]

Bueno, la versión profesional, ya no permite trabajar con motores de bases de datos Cliente Servidor (Solo conexiones locales o embebidas), tampoco tiene los componentes FireDac, ni el soporte iOS... entonces..... ¿qué tiene de profesional?... con esta situación nos empujan cada vez mas a subirnos de versión ...

Hace un tiempo pensé que Embarcadero estaba entrando en una estrategia para bajar el precio del producto de forma gradual, mediante los "productos adicionales que ofrecen", por ejemplo, el acceso a versiones anteriores nos permite tener dos licencias legales de delphi, aunque una de ellas es por lo menos una versión inferior... Yo por ejemplo adquirí la version XE y pude licenciar una 2010... cuando hice el upgrade a XE3, me dieron acceso adiconal a una XE2....

Además, estuvo ofreciendo promociones como por ejemplo, adquirir RAD o la verción ultimate por el precio de Delphi sencillo... lo cual nos da acceso a algunas versiones de las herramientas de base de datos de embarcadero


Pero... parece que no es del todo asi.... proque los precios siguen siendo muy altos y no atraen nuevos progrmadores... los que somos fanaticos del lenguaje, lo pensamos mucho antes de volver a pensar en una inversión.

Yo personalmente, sugiero esperar a que salga la versión con soporte Android... (Septiembre, diciembre, Febrero)... valdrá la pena esperar ya sea por upgrade o por nueva licencia... Al final los números mostraran a embarcadero que debe pensar mejor la estrategia de coemrcialización de sus nuevos parches-versiones. Veremos quien resiste mas....

Queeee!!, de verdad le quitaron o no tiene nada de eso la version professional??, si es asi que rayada mas grande de embarcaderos y hasta le enviaria un insulto, disculpen, pero como carajo no trae esas cosas y obligan s compra la de 2500 dolares , que pavada :o, no lo puedo cree, de verdaf que me dejarian tranquilo si desmienten esto...

[Al González]

[...] la versión profesional, ya no permite trabajar con motores de bases de datos Cliente Servidor (Solo conexiones locales o embebidas [incrustadas]) [...]
Respecto a la parte que cito, hasta donde tengo entendido esa era la intención inicial de algunos directivos en Embarcadero. Se "filtró" un mensaje de correo electrónico que hablaba de ello, algunos miembros de la comunidad protestaron, luego David Intersimone lo confirmó (cuando salió a tratar de calmar los ánimos), como consecuencia la protesta se hizo multitudinaria, y entonces fue revisada esa decisión.

Hasta donde tengo entendido, finalmente sí pueden crearse aplicaciones cliente-servidor (técnica y legalmente) con la edición Professional. Aquel intento de absurda restricción no pudo contra el sentido común. :)

Saludos.

[egostar]

.......Bueno, la versión profesional, ya no permite trabajar con motores de bases de datos Cliente Servidor (Solo conexiones locales o embebidas), tampoco tiene los componentes FireDac, ni el soporte iOS... entonces..... ¿qué tiene de profesional?... con esta situación nos empujan cada vez mas a subirnos de versión .....



.....Queeee!!, de verdad le quitaron o no tiene nada de eso la version professional??, si es asi que rayada mas grande de embarcaderos y hasta le enviaria un insulto, disculpen, pero como carajo no trae esas cosas y obligan s compra la de 2500 dolares , que pavada , no lo puedo cree, de verdaf que me dejarian tranquilo si desmienten esto...


Sólo algunas precisiones para refrescar la memoria.

1. ya no permite trabajar con motores de bases de datos Cliente Servidor (Solo conexiones locales o embebidas)

Ya lo aclaró oprtunamente Al González

2. tampoco tiene los componentes FireDac

Ni antes ni ahora, los componentes AnyDAC siempre han sido de pago, ahora las versiones entreprise y mayores lo traen "gratis"

3. ni el soporte iOS

No lo tenía XE3, porque el asombro ahora.

Saludos

[avmm2004]

.....
3. ni el soporte iOS

No lo tenía XE3, porque el asombro ahora.

Saludos

Según tengo entendido, el soporte para IOS (Ipad/ iphone ) es nuevo en XE4. El soporte para Mac, no.

Para mi una de las principales justificaciones de delphi xe4 es IOS y Android (que no estará hasta xe5 ?) en diferencia con xe2 y xe3.

Y si el tenerlos es pagar dos mil y pico euros, no gracias es demasiado para mi economía.

[egostar]

Según tengo entendido, el soporte para IOS (Ipad/ iphone ) es nuevo en XE4. El soporte para Mac, no.

Para mi una de las principales justificaciones de delphi xe4 es IOS y Android (que no estará hasta xe5 ?) en diferencia con xe2 y xe3.

Y si el tenerlos es pagar dos mil y pico euros, no gracias es demasiado para mi economía.

Puedes comprar Delphi Professional como usuario nuevo en 899 dlls mas el Mobile Add-On en 449 dlls (899+449=1348) que es mucho menos que comprar la versión Enterprise y ya puedes desarrollar para iOS. O puedes esperar a que salga Android, nadie obliga a comprar ahora.

Y sí, estoy de acuerdo que nadie está peleado con su dinero.

Saludos

[aacheron]

Con este panorama, me quedo con RAD XE Professional hasta que se soporte Android. Mala política la de embarcadero. Espero que con los componentes IBX que acaban de sacar para XE4 suavicen la metida de pata, aún así, el precio de las licencias se están disparando y no me ofrecen motivos para actualizar (iOS no me interesa en absoluto y para OSX utilizo Lazarus).

[Al González]

Algo de llamar la atención, en la nueva XE4, es que se dejará de usar Free Pascal Compiler (FPC) al crear aplicaciones para iOS.

Unlike Delphi XE2 which used the Free Pascal compiler to generate the iOS code, XE4 handles everything natively. You still, of course, need an intel-based Mac running Lion or Mountain Lion, and like with Mac OS development, Embarcadero provide the Platform Assistant (PAServer) which runs on the Mac. Your Delphi project will communicate with the PAServer on the Mac (as set in Project Options, see screenshot below), which in turn communicates with XCode via the command line to deploy your project in the iOS Simulator or onto your iOS Device.
Enlace (http://delphidisciple.blogspot.mx/2013/04/initial-thoughts-on-delphi-xe4-ios.html).

Antecedente (http://www.clubdelphi.com/foros/showthread.php?t=79227).

Saludos.

[donald shimoda]

Según tengo entendido, el soporte para IOS (Ipad/ iphone ) es nuevo en XE4. El soporte para Mac, no.

Para mi una de las principales justificaciones de delphi xe4 es IOS y Android (que no estará hasta xe5 ?) en diferencia con xe2 y xe3.

Y si el tenerlos es pagar dos mil y pico euros, no gracias es demasiado para mi economía.

No. En XE2 estaba todo el soporte (aunque no funcionaba... literalmente), que luego fue retirado en XE3 y refrito en XE4.

http://www.delphifeeds.com/go/s/103534

Saludos.

[donald shimoda]

Algo de llamar la atención, en la nueva XE4, es que se dejará de usar Free Pascal Compiler (FPC) al crear aplicaciones para iOS.


Enlace (http://delphidisciple.blogspot.mx/2013/04/initial-thoughts-on-delphi-xe4-ios.html).

Antecedente (http://www.clubdelphi.com/foros/showthread.php?t=79227).

Saludos.


Otro detalle es el regalito que le hicieron mis colegas de RemObjects : tanto la RO SDK como DataAbstracts no soportará ninguna de estas nuevas tecnologías (android, mac) a través de delphi. Porque? Bueno porque ahora se han vuelto competencia total y para ellos es mucho mas sencillo resolverlo con Oxygene. Es obvio que son dos conceptos totalmente diferentes : con Delphi usas librerías que enmascaran la real funcionalidad de la tecnología de fondo (con sus pros y sus contras) mientras con Oxygene accedes de manera directa a lo que ofrece la misma.

Otro motivo para que los usuarios de RO se pasen a Oxygene.

Estoy buscando el link donde marc hoffman lo explicaba hace días, pero no lo encuentro. Si aparece lo posteo.

[gatosoft]

Hasta donde tengo entendido, finalmente sí pueden crearse aplicaciones cliente-servidor (técnica y legalmente) con la edición Professional. Aquel intento de absurda restricción no pudo contra el sentido común. :)

Saludos.

Pues para mi es claro que no es posible, según el comparativo de versiones del producto (http://www.embarcadero.com/products/delphi/product-editions). Fíjense en el ítem(Database Application Architectures)





Sólo algunas precisiones para refrescar la memoria.

2. tampoco tiene los componentes FireDac

Ni antes ni ahora, los componentes AnyDAC siempre han sido de pago, ahora las versiones entreprise y mayores lo traen "gratis"




Es cierto que siempre han sido de pago, yo de hecho los adquirí a DevArt para mi versión XE. Sin embargo, los FireDac pretenden ser el estandar de embarcadero para Delphi, y supongo que con el tiempo irán desmontando dbExpress para irlo acopalndo a lo nuevo. Asi como con el tiempo la VCL irá pasando a segundo plano gracias a FireMonkey.

Desde este punto de vista... ¿por qué cobrar por funcionaldiades que quieren convertir en nativas?... Bueno es un punto de vista.




3. ni el soporte iOS
No lo tenía XE3, porque el asombro ahora.



Desde la salida de FireMonkey 1, se ofrece la posibilidad de construir aplicacioens para MAC... esta vez se hace de manera nativa, sin puentes con xCode... Insisto: ¿Por que cobrar, adicional a una licencia tan cara, las funcionalidades que podrían convertirse en las más utilizadas?

[donald shimoda]

Pues para mi es claro que no es posible, según el comparativo de versiones del producto (http://www.embarcadero.com/products/delphi/product-editions). Fíjense en el ítem(Database Application Architectures)


Indica que no trae componentes para ello, no que no es posiblñe o prohibido por licencia, que es a lo que se refiere Al. En su momento quisieron emitir una licencia prohibiendo acceso cliente server aun utilizando componentes de terceros.


Es cierto que siempre han sido de pago, yo de hecho los adquirí a DevArt para mi versión XE.


Como te habrá vendido Devart los Anydac?
:rolleyes:
Devart no es la empresa que producia Anydac, adquirido por EMB, ahora llamado Firedac. Da-Soft es la empresa que producía Anydac. http://www.da-soft.com/anydac/

[gatosoft]

Como te habrá vendido Devart los Anydac?
:rolleyes:
Devart no es la empresa que producia Anydac, adquirido por EMB, ahora llamado Firedac. Da-Soft es la empresa que producía Anydac. http://www.da-soft.com/anydac/

Ok, tienes razón... adquirí los UniDAC de DevArt (http://www.devart.com/unidac/), que para mi en su momento, tenían la misma funcionalidad..

[egostar]

Pues para mi es claro que no es posible, según el comparativo de versiones del producto (http://www.embarcadero.com/products/delphi/product-editions). Fíjense en el ítem(Database Application Architectures)

Es cierto que siempre han sido de pago, yo de hecho los adquirí a DevArt para mi versión XE. Sin embargo, los FireDac pretenden ser el estandar de embarcadero para Delphi, y supongo que con el tiempo irán desmontando dbExpress para irlo acopalndo a lo nuevo. Asi como con el tiempo la VCL irá pasando a segundo plano gracias a FireMonkey.

Desde este punto de vista... ¿por qué cobrar por funcionaldiades que quieren convertir en nativas?... Bueno es un punto de vista.

Desde la salida de FireMonkey 1, se ofrece la posibilidad de construir aplicacioens para MAC... esta vez se hace de manera nativa, sin puentes con xCode... Insisto: ¿Por que cobrar, adicional a una licencia tan cara, las funcionalidades que podrían convertirse en las más utilizadas?


Pues podríamos llevar ésto a una discusión bizarra y sin sentido dado que ni tu ni yo podemos cambiar (por el momento) tal disposición. Sin embargo, lo que todos tenemos es la ventaja de comprar o no comprar la nueva versión de Delphi, claro, si corresponde o no al costo/beneficio asociado a nuestros proyectos.

Saludos