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...

Es algo que siempre he pensado y por tanto comparto la misma opinión.

Aunque alguien tenga solo la copia de tu documento de identidad, con ello posee tus datos. Que no posean el original, solo limita sus posibilidades, pero no las anula todas.

El recaudo de dicha informacón, tú no puedes controlar como de fectiva es ni será, luego puede acabar en cualquier parte. Y desde luego si hay un hackeo, lo más probable es que no digan nada a nadie, especialmente si es una empresa muy pequeña o si no altera el uso de sus sistemas (se limita a robo de datos, digamos).

Incluso almacenar el número de identificación, no me parece correcto. Lo idela es que solo guardarán un hash (que debiera incorporar cada DNI), tu tas tu nombre y tecleas tu número, y el aparato en cuestión calcula el hash que debe coincidir con el que porta tu documento, ese dato es el que podían guardar junto a tu nombre.

Dado que para cualquier transacción se requeriría tu número de identidad además de tu nombre y que a dichos datos se debería calcular el hash, sin dicho número no podría arrojar un valor correcto, lueg los datos  sobre ti no sería aptos para delinnquir en tu nombre.

Naturalmente el dispositivo para introducir tu número y que calcula el hash, debería ser un dispositivo fabricado y timbrado por la casa de la moneda y timbre, y al respecto, el cálculo no debería hacerse en el dispositivo, si no en el servidor de la FMNT, el dispositivo, meramente se remitiría a aceptar los datos y cifrarlos (un cifrado que cambia con cada uso), para enviarlos a la FMNT, dnde se calcula el hash y se devuelve el resultado, que es el que se verifica que coincida con tu documento). Eso fuerta a que dichos dispositivos tuvieran siempre conectividad...

Pues sí la hay...
La más corriente es pedírselo.
Y a partir de ahí, hay muchas formas de no pedírselo, todas ilegales, o al menos alegales. Pero el foro no contribuye en ese sentido.

Si solo buscas un byte, la búsqueda puede ser secuencial (dentro de un for) y si buscas varios valores de bytes seguidos, tampoco es más complicado.



Si conoces un índice específico en el array donde se localiza, entonces el bucle for es innecesario.
Si por el contrario debe buscarse en múltiples partes, otra función debe llamar a 'ésta', y entre sí deben retener el índice donde se localiza (por referencia), el bucle ya no vale un 'for each', ya deberá ser uno desde el índice hasta el final.
Y siempre que se devuelva otro valor distinto de 'desconocido' implica que no se terminó de buscar en el array, luego la siguiente llamada continuará un índice más alto que donde se encontró. Cuando se devuelva 'desconocido', podrá leerse el siguiente tramo (caso de un fichero muy grande y no querer saturar la memoria con una lectura completa del fichero).

Si el número de bytes a localizar es mayor de 1 y este valor pueda ser variable, entonces la eficiencia la encontrarás usando el algoritmo de Knuth, Morris y Pratt (KMP), o el de Boyer y Moore (BM)... (el de Karp Rabin puede ser más farragoso para cosas simples). Típicamente se utilizan para cadenas de texto, pero una cadena de texto no dejan de ser bytes consecutivos en el fichero.
Eso sí, operando con números si ocupan más de 2 bytes ten en cuenta su 'endianidad'... pues altera el orden de ellos (caso que no ocupa cuando se trata de un texto).

Hace años edité el artículo, era un galimatías probablemente producto de una traducción (de entonces) defectuosa del inglés, sin explicaciones ni detalles específicos:
https://es.wikipedia.org/wiki/Algoritmo_Knuth-Morris-Pratt

Personalmente prefiero 'Pascal Case', en el trabajo hay que adaptarse a lo que esté en uso en tu empresa (si no hay nada establecido tira de tu preferencia, pero siendo coherente, no mezclando estilos).

Nunca he dado demasiada importancia a la capitalización, por lo que 'Camel Case', no me aporta nada significativo a nivel personal.

El lenguaje Pascal inventó la definición de tipos por su inicial, así podías indicar que todo lo que comenzara con 'a' hasta 'k' eran tipos entero. Facilitaba las cosas, pues bastaban pocas declaraciones para los (pocos) tipos que había entonces, y además en una sola declaración ya incluías como declaradas todas las variables que utilizaras luego... ...y ahí empezó a enredarse todo.

Hoy, hay bastantes 'reglas' mediocres... ...para el español (y otros idiomas). Para el inglés pueden estar bien (de hecho suelen nacer pensado en ellos), pero no para el español, porque exige en muchos casos pulsar simultáneamente 2 teclas a la vez (cuestión de teclados), por ejemplo al usar la_barra_baja_tras_cada_palabra que ralentiza la mecanografía y más aún cuando por esta causa cometes un error al tener que corregirlo, aún así no faltan estúpidos que defienden a ultranza el sistema (y sí, tienen que usar a diario un teclado en español).

Sigue sin haber una solución que satisfaga todo, pues hay gente que quiere llevar en el nombre demasiados conceptos que no le pertenecen.

- Una función debiera ser siempre un verbo (o palabras que verbalicen) 'Comprimir', 'EstaListo', 'Calcular', 'Convertir', 'Existe', 'Guardar'...
- Una propiedad debiera ser siempre el nombre de un adjetivo: 'Color', 'Alto', 'Brillo', 'Edad', 'Precio', 'Ciudad'...
- Las variables privadas, deberían usar siempre una palabra compuesta: 'ColorTinta', 'AlturaVentana', 'EdadAlumno', 'PrecioLibro', 'NombreCiudad'...

Usando nombres coherentes, el tipo básicamente queda reflejado en la mayoría de casos deducible por su significado:
- El número de colores es de varios (pocos) millones (y todo el mundo sabe que dicha magnitud es un numero, aunque se utilice un sistema de numeración no decimal).
- Una ventana no va a tener una altura de millones (y si no fuera en píxeles, añadir el sistema al nombre). Lo mismo que la altura de un edificio tendrá valores en metros y sabemos que no son millones para ninguno. 
- La edad de un alumno, queda acotada dentro de un byte. Y reflejando un numero de años, es absurdo representarlo en texto.
- Un precio es lógico que tenga decimales, indistintmente de la moneda usada.
- Una ciudad siempre es un texto (si no, pondrías 'CodigoCiudad', por ejemplo).
etc...

Entre las propiedades y las variables, la distinción semántica no es suficiente, implican lo mismo, obtener o asignar un valor (de hecho puede invertirse mi anterior entrada), la mayor distinción es para tolerar el tipo de alcance que tienen, luego el nombre puede no distinguir suficiente, ahí si podría utilizar (por sistema) la capitalización, para distinguir unas de otras.

Una clase, es en sí misma un mecanismo, y como tal puede englobar tanto funciones como propiedades e incluso ser anidadas.
En realidad con la llegada de la programación orientada a objetos, el número de entidades de programación se dispara y entonces surje una idea (en realidad vieja, pero que ahora sí queda justificada), de usar 1-3 caracteres para identificar el tipo de entidad. 'strCiudad', 'clsVehiculo', 'fncAbrir'... y ahí parece adecuado que empiece con minúscula como señalando que no es parte de la identificación del nombre si no del tipo de entidad...
 
Luego gente que aprende a programar pero no conoce la base original se monta sus propios sistemas, a veces contradiciendo lo aceptado hasta entonces, suele no prosperar, pero si el individuo en cuestión se hace famosete por alguna cuestión, parece que su criterio 'va a misa' y otros los adoptan sin rechistar, porque al igual que él, no mantienen una memoria del asunto y por tanto 'su solución' les parece más acertada que su caótico quehacer hasta la fecha.

Y si mezclas diferentes casos de este tipo, entonces al final hay quien entra a valorar mejoras y problemas de cada sistema e intenta como resumen proponer el suyo propio donde intenta reunir las mejoras y evitar los problemas, por lo general la solución adolece de otros problemas que en origen cada conjunto no contenía y que por ello éste no contempla ni se le ha pasado por la imaginación, es decir no ha aplicado a su sistema el criterio aplicado a los otros de los que parte...

... y con ello llegamos a la sopa actual, hay de todo. Sírvase al gusto, el sentido común cada vez parece ser más menospreciado.

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.

Hay como mínimo un lenguaje ensamblador por cada microprocesador distinto.

Si bien, dado que los procesadores forman 'familias' es habitual que un mismo lenguaje cubra varios procesadores.

Si se compila para 'cualquier procesador (de la familia)', se ve obligado a usar el conjunto de intrucciones comunes a todos los procesadores de la familia.
Si se compila en la máquina destino, se puede optimizar usando las instrucciones específicas que tenga dicho procesador.

Por ejemplo, para la familia Intel x86, tienes MASM, TASM, NASM, HLA...

Google y Wikipedia son páginas que debieras consultar antes de hacer preguntas aquí.
https://es.wikipedia.org/wiki/Categor%C3%ADa:Ensambladores

Juraría que ya preguntaste estas mismas cosas (o muy parecidas) tiempo atrás...

Tengo también la versión 2.2 y la 2.3... pero están en otro disco, a ver si aparecen mañana...

Primero notifica a Instagram.  Lo idela es que cada usuario estafado (el afectado), sea quien lo notifique y no alguien aparte.  Por otro lado desconozco la política de Instagram respecto de ventas en su plataforma, si se quedan al margen, o no.

La policía podrá no hacer mucho, en función del país del denunciante y su no coincidencia con el país del delincuente.

Trasteando en mis viejos discos duros, encontré este manual que seguramente muchas veces cualquiera ha deseado tener a mano...

Así que lo he subido a la pagina de descargas del foro:
https://elhacker.info/manuales/Varios/exif21.pdf