elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Guía rápida para descarga de herramientas gratuitas de seguridad y desinfección


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  ¿Crees que definir el tipo de variable es útil o perjudicial?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: ¿Crees que definir el tipo de variable es útil o perjudicial?  (Leído 2,666 veces)
Tachikomaia


Desconectado Desconectado

Mensajes: 1.224


Superhacker (es broma xD )


Ver Perfil
¿Crees que definir el tipo de variable es útil o perjudicial?
« en: 9 Septiembre 2023, 11:19 am »

Conversación con GPT:
¿Por qué en actionscript defines una variable por ejemplo así:
var count:int = 1;
cuando la puedes definir simplemente así:
count = 1;
?

Citar
En ActionScript, la declaración de variable con la palabra clave "var" seguida del tipo de dato y el nombre de la variable es una forma más explícita de definir una variable y asignarle un valor inicial. Esto se conoce como declaración e inicialización en una sola línea.

Al utilizar la sintaxis "var count:int = 1;", se está indicando que se desea crear una nueva variable llamada "count" de tipo entero (int) y se le asigna el valor inicial de 1. Esta sintaxis es útil cuando se desea especificar el tipo de dato de la variable de manera explícita y se quiere asegurar que la variable sea del tipo correcto desde el principio.

Por otro lado, la forma de definir una variable sin la palabra clave "var" es conocida como una asignación simple. En este caso, se asume que la variable "count" ya ha sido declarada anteriormente en el código. Si la variable no ha sido declarada previamente, se generará un error.

La elección de utilizar una u otra forma depende del contexto y de las preferencias del programador. Algunos programadores prefieren la declaración explícita de variables para mayor claridad y evitar posibles errores, mientras que otros pueden optar por la asignación simple cuando ya se ha realizado la declaración previa de la variable.

a mí nunca me dio error

Citar
Es posible que en tu caso específico no hayas experimentado errores al asignar directamente un valor a una variable sin utilizar la declaración explícita con la palabra clave "var". Sin embargo, es importante tener en cuenta que el lenguaje ActionScript es un lenguaje tipado, lo que significa que se espera que las variables tengan un tipo de dato específico.

Al utilizar la declaración explícita con "var count:int = 1;", estás indicando claramente que la variable "count" es de tipo entero (int) y se le asigna el valor inicial de 1. Esto ayuda al compilador a realizar verificaciones de tipo y garantizar que se utilicen las variables de manera coherente en el código.

Al omitir la declaración explícita y simplemente asignar un valor a la variable "count = 1;", el compilador de ActionScript puede inferir el tipo de dato basándose en el valor asignado. Sin embargo, esto puede llevar a confusiones o errores si el valor asignado no coincide con el tipo de dato esperado para esa variable.

En resumen, aunque no hayas experimentado errores en tu caso específico, es una buena práctica utilizar la declaración explícita con la palabra clave "var" para asegurar la consistencia y evitar posibles problemas relacionados con los tipos de datos en ActionScript.

muéstrame un ejemplo de un error

Citar
Claro, aquí tienes un ejemplo en ActionScript donde se produce un error al asignar un valor incorrecto a una variable sin utilizar la declaración explícita:

```actionscript
var count:int;
count = "1"; // Asignación incorrecta: se intenta asignar una cadena de texto a una variable de tipo entero

trace(count);
```

En este ejemplo, se declara una variable "count" de tipo entero utilizando la palabra clave "var". Luego, se intenta asignar el valor "1" como una cadena de texto a la variable "count", lo cual es incorrecto ya que se espera que la variable sea de tipo entero.

Al ejecutar este código, se producirá un error de tipo en tiempo de ejecución, y se mostrará un mensaje similar al siguiente:

```
TypeError: Error #1034: Tipo de coincidencia de valores no válida. No se puede convertir "1" en int.
```

Este error indica que se está intentando realizar una conversión no válida de una cadena de texto a un entero, lo cual es incompatible. Si se hubiera utilizado la declaración explícita con la palabra clave "var", se habría detectado el error durante la etapa de compilación y se habría evitado la ejecución del código con dicha asignación incorrecta.

pero ahí el error no ocurrió por no especificar el tipo de variable, sino por por especificar el tipo y darle un valor de otro tipo. Si no especificas el tipo se asigna según el valor y no hay problema ¿o sí puede haberlo? dame un ejemplo de que no se asigne el tipo y eso de un problema

Citar
Tienes razón, en ActionScript, si no se especifica el tipo de variable al declararla con la palabra clave "var", el tipo se asignará automáticamente según el valor asignado. Por lo tanto, no habrá un error si el tipo del valor asignado coincide con el tipo esperado para esa variable. Sin embargo, es posible que ocurran problemas si el tipo del valor asignado no coincide con el tipo esperado.

Aquí tienes un ejemplo donde no especificar el tipo de variable puede causar un problema:

```actionscript
var count; // Variable declarada sin especificar el tipo
count = "1"; // Asignación de una cadena de texto

trace(count);
```

En este ejemplo, la variable "count" se declara sin especificar el tipo utilizando "var". Luego, se le asigna el valor de la cadena de texto "1".

El problema ocurre cuando intentas realizar operaciones o utilizar la variable en contextos donde se espera un tipo de dato específico. Por ejemplo:

```actionscript
var count;
count = "1";

var result:int = count * 2; // Intento de multiplicar una cadena de texto por 2

trace(result);
```

En este caso, se intenta multiplicar la variable "count" por 2 y asignar el resultado a la variable "result" de tipo entero. Sin embargo, dado que "count" se asignó como una cadena de texto en lugar de un entero, se producirá un error en tiempo de ejecución debido a la incompatibilidad de tipos:

```
TypeError: Error #1006: No se puede acceder a la propiedad * mediante una referencia a un valor de tipo String.
```

Este error indica que no se puede realizar la operación de multiplicación en una cadena de texto.

En resumen, aunque ActionScript permite asignar automáticamente el tipo de una variable cuando no se especifica, es importante tener en cuenta que esto puede causar problemas si se utiliza la variable en contextos donde se espera un tipo de dato específico. Por lo tanto, es recomendable especificar explícitamente el tipo de variable siempre que sea posible para evitar posibles errores de tipo en tiempo de ejecución.

eso puede ocurrir incluso si se define el tipo

Citar
Tienes razón, incluso si se define el tipo de variable al declararla en ActionScript, aún es posible encontrarse con problemas si se asigna un valor incompatible con ese tipo. Aquí tienes un ejemplo:

```actionscript
var count:int = "1"; // Asignación incorrecta: se intenta asignar una cadena de texto a una variable de tipo entero

trace(count);
```

En este caso, se declara la variable "count" con el tipo de dato explícito "int". Sin embargo, se intenta asignar la cadena de texto "1" a la variable, lo cual es incompatible con el tipo entero.

Al ejecutar este código, se producirá un error de tipo en tiempo de ejecución similar al siguiente:

```
TypeError: Error #1034: Tipo de coincidencia de valores no válida. No se puede convertir "1" en int.
```

Este error indica que se está intentando realizar una conversión no válida de una cadena de texto a un entero, lo cual es incompatible.

La especificación del tipo de variable al declararla en ActionScript ayuda al compilador a realizar verificaciones de tipo durante la etapa de compilación. Sin embargo, no garantiza que los valores asignados sean siempre compatibles con el tipo especificado. Es importante asegurarse de asignar valores que sean del tipo esperado para evitar errores de tipo en tiempo de ejecución.

lo que te digo es que incluso definiendo el tipo y el valor acorde al tipo, si luego intentas usar esa variable en contextos que dará error, entonces dará error, entonces el problema no es no definir el tipo, sino asignarle un valor y querer usarlo en contextos en que no encaja. Por eso definir el tipo es inútil

Citar
Tienes razón, pido disculpas por la confusión anterior. Si definiste el tipo de variable correctamente y asignaste un valor compatible con ese tipo, no deberías encontrar problemas al utilizar la variable en contextos adecuados.

La ventaja de definir el tipo de variable explícitamente es que proporciona claridad y ayuda a prevenir posibles errores al asignar valores incorrectos. Además, también permite al compilador realizar comprobaciones de tipo durante la compilación, lo que puede ayudar a identificar errores antes de tiempo.

Sin embargo, es importante tener en cuenta que la definición del tipo de variable no garantiza por sí sola que no se produzcan errores en el uso posterior de la variable. Si intentas utilizar la variable en contextos incompatibles con su tipo, como realizar operaciones no válidas o pasarla como argumento a una función que espera un tipo diferente, es posible que se produzcan errores.

En resumen, definir el tipo de variable puede ser útil para mejorar la legibilidad del código y prevenir errores de asignación de valores incompatibles. Sin embargo, aún es necesario tener en cuenta el contexto de uso de la variable y asegurarse de utilizarla de manera coherente con su tipo especificado.

Bueno señores, si dice que ayuda a la compilación a detectar errores en ella, no puedo demostrar lo contrario, pero definitivamente una variable más clara es una que incluye simplemente su nombre y su valor, yo veo ese "var" y lo demás y me da una especie de ataque de nervios  :laugh:

Para saber cómo quiero usar una variable pienso qué tipo de valor tenía, memorizo el valor inicial o el que haya definido por última vez, no necesito definir el tipo.

En fin, cada uno haga lo que quiera.


En línea

Elektro Enjuto

Desconectado Desconectado

Mensajes: 121



Ver Perfil WWW
Re: ¿Crees que definir el tipo de variable es útil o perjudicial?
« Respuesta #1 en: 9 Septiembre 2023, 14:45 pm »

¿Crees que definir el tipo de variable es útil o perjudicial?

No es cuestión de creencias personales, perjudicial no es en ningún sentido, aunque en el contexto de un lenguaje de scripting el impacto puede ser mucho menos significativo (sobre todo si se está usando un editor de texto simple), pero, generalizando y ampliando la respuesta a otros lenguajes de programación, escribir código sin especificar de forma explícita el tipo de las variables/objetos solo sirve para reducir el tiempo de escritura del programador a costa de perjudicar la comprensión y claridad del código, entre otros inconvenientes en tiempo de compilación y de diseño, como imposibilitar la detección temprana de errores del depurador, e imposibilitar la resolución de un enlace estático para beneficiarse del autocompletado de código.

En resumen, y generalizando y ampliando de nuevo a otros lenguajes, puede considerarse (yo lo considero) una mala costumbre y propensa a cometer errores humanos. Puede resultar útil en escenarios donde pueda ser considerado más viable recurrir a la resolución de tipos en tiempo de ejecución (late-binding), pero creo que poco o nada más. Prefiero la claridad de código ante todo, definiendo de forma explícita el tipo de cada variable.

yo veo ese "var" y lo demás y me da una especie de ataque de nervios  :laugh:

Eso me pasa a mi cuando veo un código de C# escrito por otra persona y lleno de "var". Lo considero una costumbre horrible, pero al final es una cuestión de preferencias, y si el lenguaje ofrece esa posibilidad es para que haya gente que opte por la escritura de código basada en la inferencia de tipos. Además, por suerte y por muchos "var" que haya en un código de C# es algo que se soluciona de forma simple con dos clicks en la IDE de Visual Studio.

Saludos.


« Última modificación: 9 Septiembre 2023, 15:08 pm por Elektro Enjuto » En línea

@%$& #$ %&#$, ¡hay que decirlo más!.
Serapis
Colaborador
***
Desconectado Desconectado

Mensajes: 3.357


Ver Perfil
Re: ¿Crees que definir el tipo de variable es útil o perjudicial?
« Respuesta #2 en: 28 Septiembre 2023, 11:49 am »

Conversación con (Chat) GPT:
Bien, al final te has animado a conversar con ChatGPT...
Tiene la 'paciencia' adecuada para soportar preguntas insulsas (digamos tediosas de responder por absurdas, simples, o ridículamente complejas), así que no quedarás defraudado.

Si su nivel de respuesta te resulta complejo, aún puedes anteceder tus preguntas si al inicio de la conversación de sueltas un: "De aquí en adelante, explicáme todo lo que te pregunte en esta conversacióm como si tuviera 12 años." y así usará términos más comprensibles, incluso pedirle que no utilice jerga.


Respecto de tu cuestión...
Te diría: "Sí, tienes razón, pero solo cuando tus programas se limiten a 25 líneas de código."

Escribe un programa o algoritmo con 2.000 líneas de código... deja que pasen solo 6 meses e intenta leer el código que tu mismo hiciste y te verás perdido, cuaánto más si el código lo hizo otra persona y por tanto no partes con la ventaja de "yo suelo hacer esto y esto y dar estos nombres por esto y esto", y tener que enfrentarte a otro pensamiento con ideas más o menos lógicas (según tu punto de vista), pero con las que tendrás que lidiar.

A la hora de programar (excepto que sea solo para tí), tienes que prestar atención a la claridad del código, lo que implica declarar el tipo de todas las variables, darles nombres significativos, huir de las funciones de 10 páginas, añadir comentarios acordes el objetivo y lo que hace cada cosa, etc...

La programación es un reflejo del pensamiento... si tu programación es caótica, también lo es tu pensamiento. Poner orden, no solo aclara el código, también las ideas en tu mente.

Es cierto que a veces ofuscar el código puede ser parte intencional desde el principio, pro no cuando se pretende exponer código a otras personas para que lo revisen o te den su opinión.
« Última modificación: 28 Septiembre 2023, 11:57 am por Serapis » En línea

Tachikomaia


Desconectado Desconectado

Mensajes: 1.224


Superhacker (es broma xD )


Ver Perfil
Re: ¿Crees que definir el tipo de variable es útil o perjudicial?
« Respuesta #3 en: 29 Septiembre 2023, 20:16 pm »

Bien, al final te has animado a conversar con ChatGPT...
Descubrí una manera de usarlo sin dar un número de celular, no sé si es "animarse", yo no hubiera tenido problema en usarlo antes si no me hubieran pedido eso, y no lo estaría usando si no hubiera descubierto lo que dije. Es usando Quora, haces una pregunta en inglés, te da la opción de usarlo, lo usas, guardas el link y gualá.
Por cierto, se te extrañaba xP

Citar
Tiene la 'paciencia' adecuada para soportar preguntas insulsas (digamos tediosas de responder por absurdas, simples, o ridículamente complejas), así que no quedarás defraudado.
Pero lo más complejo no lo entiende, o sea, cuanto más útil podría ser, menos lo es. Lo que sí, puede ayudar a resolver los problemas uno mismo o entenderlos mejor porque mientras uno se los intenta hacer entender lo entiende mejor uno mismo. Otra cosa para la que anda bien es para hacer cosas con palabras, por ejemplo le pedí acciones relacionadas con videojuegos y me dijo varias que yo hubiera tardado en recordar.

Describiendo cierto código entendí mejor lo que hace. Es extraño, a veces uno entiende que ciertas cosas funcionan pero no entiende cómo explicarlas o incluso en unos momentos tiene más lucidez que en otros y lo que entendió en un momento no lo entiende luego.

Para muestra (2021):
Código
  1. Escena 1
  2.   actions for fotograma 1
  3.      // Situación inicial.
  4.      BaseEnHP = 10;
  5.      // Guardar Situación inicial.
  6.      SitID = "S"+BaseEnHP;
  7.      set (SitID+"EnHP", BaseEnHP);
  8.      set (SitID+"Action", "Ninguno");
  9.      Action = 1;
  10.      // Variables de Unsolved situaciones.
  11.      U = 0;
  12.      Us = 0;
  13.   actions for fotograma 2
  14.      // Reset Situación. Aplicación.
  15.      EnHP = BaseEnHP-Action;
  16.      // ¿Sol?
  17.      if (EnHP<=0) {
  18.         // Solución; iniciar mostrar lista.
  19.         List = Action;
  20.         gotoAndPlay (4);
  21.         // Sino ¿la situación está anotada?
  22.      } else if (eval("S"+EnHP+"EnHP") == undefined) {
  23.         // No. Anotarla.
  24.         SitID = "S"+EnHP;
  25.         set (SitID+"EnHP", BaseEnHP);
  26.         set (SitID+"Action", Action);
  27.         Us = Us+1;
  28.         SitID = "U"+Us;
  29.         set (SitID+"EnHP", EnHP);
  30.      }
  31.   actions for fotograma 3
  32.      // La situación existe. ¿Modificar candidato es posible?
  33.      if (Action<2) {
  34.         // Modificación de candidato.
  35.         Action = Action+1;
  36.         gotoAndPlay (2);
  37.      } else if (U<Us) {
  38.         // Usar Unsolveds.
  39.         U = U+1;
  40.         BaseEnHP = eval("U"+U+"EnHP");
  41.         Action = 1;
  42.         gotoAndPlay (2);
  43.      } else {
  44.         // No hay Solución.
  45.         List = "No hay sol";
  46.         stop ();
  47.      }
  48.   actions for fotograma 5
  49.      SitID = eval("S"+BaseEnHP+"Action");
  50.      BaseEnHP = eval("S"+BaseEnHP+"EnHP");
  51.      if (SitID != "Ninguno") {
  52.         List = SitID+" "+List;
  53.         gotoAndPlay (4);
  54.      } else {
  55.         stop ();
  56.      }

Lo mismo 2023:
Código
  1. Escena 1
  2.   actions for fotograma 1
  3.      Respuesta = "Vencer al enemigo mediante acciones, el enemigo tiene 11 HP. Se recomienda la serie... ";
  4.      // Situación inicial:
  5.      // HP inicial del enemigo:
  6.      EnBaseHP = 11;
  7.      trace ("EnBaseHP: "+EnBaseHP);
  8.      // Guardar situación y cómo se produjo:
  9.      // Esta variable es el principio del nombre de los datos, en este caso S11:
  10.      SitID = "S"+EnBaseHP;
  11.      trace ("SitID: "+SitID);
  12.      // Esta variable marca qué acción se realizó en la situación anterior, en este caso ninguna:
  13.      set (SitID+"ActionAnterior", "Ninguna");
  14.      trace (SitID+"ActionAnterior: "+eval(SitID+"ActionAnterior"));
  15.      // En este caso la variable es S11Action="Ninguna".
  16.      // Acción que será usada 1ero:
  17.      Action = 1;
  18.      trace ("Action: "+Action);
  19.      // Variables sobre situaciones anotadas:
  20.      // Total de situaciones anotadas:
  21.      As = 0;
  22.      trace ("Situaciones anotadas: "+As);
  23.      // Situación anotada que será investigada 1ero:
  24.      A = 0;
  25.      trace ("Situación anotada a investigar cuando se comience a investigar las anotadas: "+A);
  26.   actions for fotograma 2
  27.      // Reset de la situación. Aplicación de la acción:
  28.      EnHP = EnBaseHP-Action;
  29.      trace ("Reset de la situación, aplicación de la acción, la situación ahora es:");
  30.      trace ("EnHP: "+EnHP);
  31.      // ¿Se logró el objetivo?
  32.      if (EnHP<=0) {
  33.         // Sí, iniciar muestra de serie de acciones que la causan:
  34.         Serie = Action;
  35.         trace ("Solución hallada, iniciando proceso para mostrar respuesta.");
  36.         gotoAndPlay (4);
  37.      } else {
  38.         // No se logró el objetivo.
  39.         trace ("No se logró el objetivo.");
  40.         // ¿La situación producida está anotada?
  41.         if (eval("S"+EnHP+"EnHPAnterior") == undefined) {
  42.            trace ("La situación producida no está anotada.");
  43.            // La situación no está anotada, anotarla y cómo se logró:
  44.            SitID = "S"+EnHP;
  45.            set (SitID+"EnHPAnterior", EnBaseHP);
  46.            set (SitID+"ActionAnterior", Action);
  47.            trace ("Nueva situación anotada: "+SitID);
  48.            trace ("Su antecedente fue ("+SitID+"EnHPAnterior): "+EnBaseHP);
  49.            trace ("y la acción fue ("+SitID+"ActionAnterior): "+Action);
  50.            // También se agrega como situación a investigar y se anota en qué consiste:
  51.            As = As+1;
  52.            SitID = "A"+As;
  53.            set (SitID+"EnHP", EnHP);
  54.            trace ("Situaciones anotadas: "+As);
  55.            trace ("La última consiste en (EnHP): "+eval(SitID+"EnHP"));
  56.         } else {
  57.            trace ("La situación producida ya está anotada.");
  58.         }
  59.      }
  60.   actions for fotograma 3
  61.      // La situación existe. ¿Modificar acción es posible?
  62.      if (Action<2) {
  63.         // Sí, modificarla:
  64.         trace ("Es posible modificar acción.");
  65.         Action = Action+1;
  66.         trace ("Action fue modificada, es: "+Action);
  67.         gotoAndPlay (2);
  68.      } else {
  69.         // No es posible modificar la acción.
  70.         trace ("No es posible modificar la acción.");
  71.         if (A<As) {
  72.            // Aún hay situaciones anotadas sin investigar, investigar una (probablemente lo ideal sería investigar la más diferente a las investigadas, pero me es difícil programar eso):
  73.            trace ("Aún hay situaciones anotadas sin investigar.");
  74.            A = A+1;
  75.            EnBaseHP = eval("A"+A+"EnHP");
  76.            trace ("Se investigará la situación anotada nro: "+A);
  77.            trace ("Consiste en EnBaseHP: "+EnBaseHP);
  78.            Action = 1;
  79.            trace ("Reset de la acción a usar, es: "+Action);
  80.            gotoAndPlay (2);
  81.         } else {
  82.            // No hay situaciones anotadas sin investigar.
  83.            Respuesta = "No es posible lograr el objetivo.";
  84.            trace ("No hay situaciones anotadas sin investigar ni es posible lograr el objetivo.");
  85.            stop ();
  86.         }
  87.      }
  88.   actions for fotograma 5
  89.      // Obtener acción anterior:
  90.      ActionAnterior = eval("S"+EnBaseHP+"ActionAnterior");
  91.      trace ("La acción anterior fue: "+ActionAnterior);
  92.      // ¿Hubo?
  93.      if (ActionAnterior != "Ninguna") {
  94.         // Sí, agregarla en la lista:
  95.         Serie = ActionAnterior+" "+Serie;
  96.         trace ("Acción agregada en la serie.");
  97.         // Averiguar cual fue la situación anterior:
  98.         EnBaseHP = eval("S"+EnBaseHP+"EnHPAnterior");
  99.         trace ("Se realizó en la situación: S"+EnBaseHP);
  100.         // Repetir este frame.
  101.         gotoAndPlay (4);
  102.      } else {
  103.         // No hubo una acción anterior, mostrar la serie:
  104.         Respuesta = Respuesta+Serie;
  105.         stop ();
  106.      }
  107.  
Y aún me confunde lo de "anterior"... Pero toma más tiempo hacer los comentarios y traces que hacer el código xP
« Última modificación: 29 Septiembre 2023, 20:20 pm por Tachikomaia » En línea

Serapis
Colaborador
***
Desconectado Desconectado

Mensajes: 3.357


Ver Perfil
Re: ¿Crees que definir el tipo de variable es útil o perjudicial?
« Respuesta #4 en: 29 Septiembre 2023, 22:11 pm »

Sí, si tienes que darle demasiados detalles a ChatGPT para que te haga las cosas, es más rápido hacerlas tú mismo.

Aún así insisto en que lo uses todo lo que puedas, por dos razones:

- Puedes aprender cosas 'simples' que en cierto modo ya sabes pero que desconoces el término correcto (problema de hacerte entender con claridad).
- Te ayudará esa dinámica a ordenar mejor tus ideas y ver todo más claro... es como un profesor particular, con la gran ventaja de que no se va a cansar o aburrir porque le preguntes cosas que uno da por hecho que todo el mundo las sabe o que debiera saberlas, además te lo dirá siempre con educación (la paciencia humana humana tienes sus límites al margen de la personalidad de cada uno).

No creo que sea tan relevante que te pida el número de teléfono... si fuera una empresa 'Nisu', todavía, pero ya es conocida, no son timadores tratando de sacarte datos para robarte... pero a fin de cuentas cada cual tiene sus manías, así que como bien te parezca a tí.

Recuerda que no es realmente una inteligencia artificial. Tampoco tiene una 'memoria' (de cara al usuario) demasiado grande... si haces conversaciones demasiado largas, los primeros datos los va 'olvidando' salvo aquellos que se han ido repitiendo. El algoritmo exacto de como retiene sus datos lo desconozco, no dan detalles, pero asumo que es alguno de tipo LRU (Last Recent Used, lo usado más recientemente).
Todavía esta incomodidad sirve para que tú mismo formalices una forma más depurada de hacer las preguntas precisamente para evitar los susodichos problemas. Es como un juego, un reto constante en el que a base de ensayo y error (juego y 'game over'), vas mejorando...

Otra ventaja que tiene es la inmediatez, si te surge una duda de repente, abres el navegador en tu tf. y buscas la pestaña (se supone que la tendrás guardada)... y en nada preguntas y tienes respuesta.

Si 30 veces le preguntas lo mismo, puede responderte cada vez cosas diferentes aún siendo una misma respuesta. Es como preguntar a 30 personas distintas... puedes verlo como una incapacidad o como algo estimable. Sería bastante aburrido que si cada persona en el mundo le hiciera la misma pregunta diera siempre exactamente palabra por palabra la misma respuesta. Es más natural así, si no parecería un libro ya escrito... y es precisamente eso, que no es un libro escrito, si no que cada vez elabora una respuesta en base a la pregunta y algún valor aleatorio, que puede arrojar una misma respuesta pero con diferentes palabras.

Yo lo he probado bastante, para conocer sus límites, capacidades, variaciones... y por ejemplo al pedirle determinado algoritmo, te lo da en un lenguaje, se lo pides otra vez pero le reclamas que no use ese lenguaje si no otro, y así sucesivamente 20 veces, incluyendo cada vez en la lista de lenguajes a no usar el último usado en su respuesta. El código subyacente suele ser muy similar, se nota a veces que su respuesta es traducida directamente de otro lenguaje. Y por ello a veces podrá darte líneas de código que no son aceptables en el lenguaje en que responde. Si no eres capaz de entender esas líneas erróneas siempre podrás decirle que esas líneas no están en el lenguaje solicitado que las reescriba en el lenguaje que le solicitas.

No siempre hace todo bien, y el código la mayor parte de las veces (especialmente si es complejo, largo o no tiene en su base de datos nada similar), suele adolecer de eficiencia. Pero yo siempre he pensado que la eficiencia debe aportarla uno, de hecho en el foro acostumbro a dar respuestas (cuando adjunto código), que el interesado pueda optimizar... es una forma de saber si de verda presta interés o solo quiere código hecho, si es lo último tendrá la penalización de no ser eficiente, si es lo primero, él mismo lo cambiará (al tiempo que se sentirá orgullosos de haberse dado cuenta y haber sido capaz de lograrlo, ganará con ello más entusiasmo por este mundillo).

Recuerda que puedes guardar las conversaciones...
En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines