Re: Simbolos dentro de cadenas y el codigo propuesto

Gabriel Colina dijo [Wed, Mar 14, 2007 at 10:55:31PM -0500]:
> > ¿Mi crítica principal a esto? Recuerda que los
> > lenguajes de
> > programación están hechos como herramienta de
> > comunicación entre
> > humanos, con suficiente formalismo para ser capaces
> > de ser traducidos
> > a algo que una computadora pueda entender. Entonces,
> > ¿por qué no
> > comenzar indentando bonito y poniendo nombres en
> > simple y llano inglés
> > a las cosas?
>
> Usar formalismos uso, me baso en la notacion Hungara.

En parte a eso me refiero: Hay lenguajes, como C, que hoy en día se
usan para trabajar "cerca de los fierros", para hacer aplicaciones muy
grandes y de bajo nivel que requieren tanta optimización como sea
posible. Esos lenguajes, claro, requieren del programador que se
encargue de manejar los tipos de datos. Pero para la mayor parte de
las aplicaciones que vas a ver que tienen relación con bases de datos,
tener que pensar en esos detalles resulta innecesario - Si tu
compilador puede manejar automáticamente la conversión de tipos y
presentarte de una manera lógica la sobrecarga de operadores cada que
esta sea requerida, ¿para qué molestarte en usar notación húngara?
¿Para qué estarle recordando a cada paso al usuario qué es lo que
determinada variable debe contener?

> La identacion existe en Visual y la uso siempre.

Ok, se habrá perdido en el ejemplo que mandaste.

> Entiendo lo del ingles y lo acepto a reganiadientes
> por que estamos en la era de la globalizacion y por
> que ya hay años de desarrollo pionero en ingles, pero
> no lo comparto.

No, no es que escriba en inglés por poder recibir ayuda de extranjeros
(aunque es un buen hábito, especialmente si estás acostumbrado a poner
tu código a disposición del mundo) - Los lenguajes de programación
están modelados siguiendo al inglés, y un humano puede leerlos casi
casi como si fueran inglés omitiendo o agregando algunos detalles
sintácticos. Te facilita la comprensión del código.

> Y si lo decis por que el ingles es un lenguaje que se
> adapta mas al de comandos, por que es imperativo.
>
> Mejor usamos Japones o Coreano, son imperativos por su
> naturaleza marcial mas que el ingles.

No, claro, ese argumento es ridículo.

> (...)
> Gracias por que esto lo voy a mejorar.
> Pero es semantico, funcionar funciona igual.

Pero acá te insisto: El lenguaje no es para que "de funcionar
funcione", sino para expresar tus ideas formales, que la computadora
seguro va a entender, de modo que otro humano pueda hacerlo.

> Y tambien una opinion experta me comento aqui que las
> funciones que no se completaban hacian rollback de
> forma automatica,

Ok, con eso me retracto de parte del regaño ;-)

> de todas maneras tengo en Visual un
> On error resume ErrControl
>
> y un
> ErrControl:
> codigo control errores

Ok. Supongo que es equivalente al bloque eval que yo incluí.

> Si no lo dudo pero, no entiendo de Perl, pero me
> parece muy parecido a lo que Gabriel Ferro intento
> hacer desde Visual y aca se le critico.
>
> Esto que viene es chanza para aflojar
>
> Y tambien veo que no te tomaste el tiempo de poner
> nombres a las variables jeje.

No le puse nombre a dos variables: @_ y $(at)(dot) Estas son dos variables
especiales en Perl (y uno de los puntos que más se le critican al
lenguaje), el arreglo de parámetros recibidos y el error devuelto por
el último bloque. Y, bueno, a @_ formalmente sí le puse nombre,
asignándolo a tres variables escalares ;-)

> Ya que estas aconsejanos un buen lenguaje compilado
> que ademas sea productivo.

Hoy en día, puedo recomendarte Perl y Ruby. Habrá quien te recomiende
Python, pero a mí nunca me ha parecido cómodo. ¿Que no son compilados?
¡Claro que sí lo son! Son compilados como un paso previo a la
ejecución, utilizando un compilador tremendamente ágil - Pero no, no
son interpretados.

> Y mil gracias nuevamente por tus aportes. como dijo
> Alvaro, los que venimos de M$, aca tenemos que venir a
> aprender.

Los que estamos en Linux desde hace diez años también ;-)

¡Saluods!

--
Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF