Swift es ahora opensource (Siguiente generacion lenguaje Apple)

[roman]

A mi no me disgusta la sintaxis tipo C, de hecho me es mucho más cómoda y me parece más elegante que los begin end de pascal. Eso sí, C++ se me hace muy enredado con tanta directiva.

Nunca he entendido esa posición de personas que trabajan con la abstracción y no pueden ver un par de {} , pero, al final de cuentas, es una cuestión de gustos. A mi, por ejemplo, no me luce bonito perl, pero no me atrevería a descalificarlo.

Empezado por AgustinOrtu

Embarcadero/Ideria solo tiene un producto fuerte, si lo liberan, se quedan sin comer, es asi de sencillo

Pero, se supone que IDERA es bastante más que lo que acaba de comprar ¿no?

// Saludos

[mamcx]

Empezado por roman

Nunca he entendido esa posición de personas que trabajan con la abstracción y no pueden ver un par de {} , pero, al final de cuentas, es una cuestión de gustos. A mi, por ejemplo, no me luce bonito perl, pero no me atrevería a descalificarlo.

A mi en lo personal desde que trabajo con python, me parece que los begin/end y los {} son ambos superfluos. Estan ahi mas que nada para simplificar el parser (lo que he podido comprobar cuando intente hacer uno para un lenguaje propio) pero no aportan mas que ruido sintactico. Pero me parece mas legible los begin/end -- y en el primer prototipo de mi lenguaje, solo sobrevive el end --.

La razon? Es porque es mas "regular". Tenemos FOR, IF, FUNCTION, etc y de pronto se atraviesan los {} que hacen mas parte de los +, -, *, [, etc.

En fin...

Me parece raro que siempre que hacen nuevos lenguajes justifican el uso de los {} (y cosas similares) disque por la familiaridad con la familia C. En el caso de swift, no es tan de la familia, y eso lo hace ver un poco bizarro a veces.

Ahora bien, comparado con obj-c... es todo un avance inmenso.

[[Al González]]

Empezado por mamcx

En el caso de swift, no es tan de la familia, y eso lo hace ver un poco bizarro a veces.

Creo que era otra la palabra que quisiste usar, Mario, porque para lenguajes verdaderamente bizarros no hay como Object Pascal (Delphi). Éste sí que es muy bizarro.

¡Un abrazo!

[mamcx]

Me vengo a enterar de la definicion original de bizarro. Yo voy por como explica http://conceptodefinicion.de/bizarro/

[roman]

Empezado por mamcx

A mi en lo personal desde que trabajo con python, me parece que los begin/end y los {} son ambos superfluos. Estan ahi mas que nada para simplificar el parser (lo que he podido comprobar cuando intente hacer uno para un lenguaje propio) pero no aportan mas que ruido sintactico. Pero me parece mas legible los begin/end -- y en el primer prototipo de mi lenguaje, solo sobrevive el end --.

Bueno, como lo veas, es necesario un begin y un end. Python lo hace mediante la indentación pero básicamente es lo mismo.

A mi en particular me choca y me sorprende que tengamos tantos prejuicios hacia determinados lenguajes, tan sólo porque nos "lucen" feos. Más aún cuando se trata de lenguajes que han probado una y otra vez ser eficientes y exitosos.

// Saludos

[Casimiro Notevi]

Una de las cosas que más me gusta del lenguaje C es precisamente que es conciso, breve, escueto y sobrio. ¿Para qué escribir begin end si puedo escribir { }, para qué escribir x:=x+1 si puedo escribir x++?

[[AgustinOrtu]]

Empezado por Casimiro Notevi

Una de las cosas que más me gusta del lenguaje C es precisamente que es conciso, breve, escueto y sobrio. ¿Para qué escribir begin end si puedo escribir { }, para qué escribir x:=x+1 si puedo escribir x++?

Yo creo que lo de begin..end o el { } es mas cuestion de gustos que otra cosa, a mi en particular no me molesta ninguno de los dos, no siento que pierdo tiempo en eso ni tampoco encuentro a uno mas legible que el otro

Con respecto al x++ si te diria que estoy de acuerdo, pero en Delphi es mas o menos reemplazable por el Inc(x), Inc(x, 2)



Lo que si seria lindo poder hacer en Delphi es esto:

Código PHP:

  double saldo = 0;

  if AlgunBoolean {
   Persona p = new Persona();
   saldo  = p -> CalcularSaldo;
  }

  p -> SayName(); // error, p no esta dentro del "scope" (alcance) 


Tres cosas que si me molestan de Delphi:

1. Declarar todas las variables arriba dentro de la clausula var. No le encuentro ninguna ventaja, no me vengan con que "es mas ordenado", yo creo que mas bien al contrario, es un caos: Ya que tenes que ir hasta arriba a declarar la variable lo cual me quita de foco de lo que estoy haciendo, y ni bien aunque haya expertos o plugins que lo "hagan automatico" sigo pensando que es una estupidez; en este sentido Delphi debe madurar.

Quien no ha reusado nunca la variable I: Integer del bucle for para cualquier otra cosa? Si se pueden declarar las variables en el momento que se usan:

a. Seguramente tenga un nombre mas acorde a lo que vas a usar --> codigo mas facil de leer, de entender, de depurar y mantener, y autodocumentado
b. Seria realmente una buena idea poder limitarle el alcance como lo hacen en C

2. La sintaxis lambda creo que apesta: tener que escribir

Código Delphi [-]
  TThread.Queue(NIL, procedure
  var
   X, B: Integer;
  begin

  end);

Es pura "ceremonia" y realmente va en contra del dogma de Pascal de "codigo claro, conciso y legible"

3. Los for en Delphi solamente se pueden incrementar de a 1... en serio, es una total ridicules!

[Casimiro Notevi]

Empezado por AgustinOrtu

Tres cosas que si me molestan de Delphi:
1. Declarar todas las variables arriba dentro de la clausula var.

A mí es una de las cosas que más me gustan, así estoy seguro de que no hay ningún olvido ni confusión.

[Delfino]

Opinion sobre C y Pascal aqui

[[Al González]]

Empezado por AgustinOrtu

1. Declarar todas las variables arriba dentro de la clausula var. No le encuentro ninguna ventaja, no me vengan con que "es mas ordenado", yo creo que mas bien al contrario, es un caos: Ya que tenes que ir hasta arriba a declarar la variable...

¿Qué tan "arriba" tendrías que ir?

Empezado por AgustinOrtu

2. La sintaxis lambda creo que apesta: tener que escribir

Código Delphi [-]
  TThread.Queue(NIL, procedure
  var
   X, B: Integer;
  begin

  end);

Es pura "ceremonia" y realmente va en contra del dogma de Pascal de "codigo claro, conciso y legible".

Hay que tener cuidado con los dogmas de cualquier tipo, y no confundirlos con las recomendaciones y buenas prácticas.

Los métodos anónimos, que son una especie de rutinas contextualizadas, forman parte de esos pequeños pero importantes avances que ha tenido la programación. Donde quiera que una función de retrollamada —callback— necesitaba llamarse pasándole varios parámetros dados previamente por el instalador de la misma, a menudo aplicando enrevesados moldes de tipo sobre ellos, ahora puede emplearse un procedimiento sencillo como el de tu ejemplo, reduciendo en buena medida la complejidad del código y volviéndolo, por cierto, más «claro, conciso y legible». Lo copio y pego con unos pequeños retoques:

Código Delphi [-]
  TThread.Queue (Nil,
    Procedure
    Var
      X, B :Integer;
    Begin
      //...
    End);

Un cordial saludo.

Al González.

[roman]

Declarar las variables "arriba" es parte del buen orden que tiene pascal. Es cierto que en ocasiones se antoja no tener que declarar hasta el más insulso contador en la sección var, pero, en general, cuando estás leyendo código ajeno (o propio después de un tiempo), es bueno saber dónde encontrar la declaración de una variable en lugar de estar escaneando el código.

En cuanto a las funciones anónimas, la realidad es que son como las variables declaradas donde sea. Son útiles en casos específicos pero siempre y cuando no se abuse.

LineComment Saludos

[Ñuño Martínez]

He estado echándole un vistazo al Swift ese, y es bien feo. no me gusta. Me parece muy confuso.

Empezado por AgustinOrtu

3. Los for en Delphi solamente se pueden incrementar de a 1... en serio, es una total ridicules!

Eso no es cierto, también se pueden incrementar en -1.

De todas formas, no me parece tan ridículo. Los bucles FOR de casi cualquier lenguaje no son más que bucles WHILE optimizados (sobre todo en C). Si quieres incrementar por otro valor, tienes varias formas: hacer tu propio bucle WHILE o REPEAT (tampoco cuesta tanto), o multiplicar el valor contador por el incremento que necesites. Por ejemplo:

Código Delphi [-]
VAR
  Contador: INTEGER;
BEGIN
  Contador := 1;
  WHILE Contador < 21 DO
  BEGIN
    HacerAlgoCon (Contador);
    INC (Contador, 4)
  END;
{ Otra forma: }
  FOR Contador := 0 TO 4 DO
    HacerAlgoCon ((Contador * 4) + 1)
END.

Sí es verdad que a veces echo de menos los bucles de BASIC:

  DIM Contador AS INTEGER

  FOR Contador = 1 TO 20 STEP 4
    CALL HacerAlgoCon (Contador)
  NEXT Contador

Nota: La verdad es que no estoy seguro de que todos los bucles hagan lo mismo, pero se pilla la idea, ¿no?