Mensajes

Nada que objetar si se aplicara exclusivamente a aquellos ficheros creados con menos de 24 horas.

[la programación no es un fin en sí mismo, sino un medio]

...Y muchos programadores recurren a ellas sin saber poco o nada de arboles o grafos. Ya que estos estan implementados en ellas. No digo que se deba reinventar la rueda, pero al menos tener unos minimos antes de recurrir a estos modulos o librerias.

Al principio los programadores allá de los años 50, no querían ni oir hablar de lenguajes de alto nivel ni programas ya escritos. Para ellos, todo el que no supiera tratar en modo máquina era un lego en la materia, un intruso... En realidad temían que si cualquiera pudiera programar ellos perderían su trabajo.

No ha cambiado mucho esa visión a día de hoy. Sigue habiendo gente que cree que un programador es tal o cual cosa y si no, es un intruso, pero nos guste o no (y que conste que yo creo que un programador (que aspire a ser profesional), debe tener una base profunda y detallada), la programación no es un fin en sí mismo, sino un medio, una herramienta de la que nos valemos para lograr otras cosas, por lo que es imparable su curso, ni puede ser 'retenido' o circunscrito a determinados baremos (estos irán y vendrán y cambiarán con el tiempo, para bien, para mal, vuelta a cambiar) ...lo que quiere decir que cualquiera que pueda valérselas para dar solución a un problema es un 'programador' y su 'producto' válido...

Más claro... no es preciso saber como funciona el motor ni otras partes mecánicas de un vehículo para ser conductor. Y a nivel de programación acabará pasando lo mismo, porque como comentaba al inicio de este mensaje es algo que ya pasó en sus inicios y diría que ha pasado y pasará en cada generación. Llegará un momento, en que la especialización será nula, pero las herramientas tan genéricas que todo el mundo será programador de una manera u otra, es decir como herramientas todo el mundo será capaz de usarlas, aunque luego solo unos pocos alcancen en profundidad a saber como funciona (como los mecánicos con los vehículos).

Todos sabemos que python, muchas veces, te da las cosas casi hechas. Y no es raro ver a gente que dice que domina un lenguaje o varios, y en cambio, no sabe hacer algoritmos de ordenacion, ni estructuras de arboles o grafos. Porque claro, si solo nos limitamos a conocer las estructuras simples es muy facil decir que uno domina mil lenguajes.

Confundes (pasa habitualmente), el lenguaje con las extensiones del lenguaje.

Un lenguaje por lo común se remite a unas pocas decenas de 'keywords', y una especificación que explica cada parte que compone el lenguaje. Eso es el lenguaje, el resto son extensiones del lenguaje que simplemente lo enriquecen. Es decir programas librerías que extienden la utilidad del lenguaje.

De hecho cuando un lenguaje carece de ciertas extensiones lo primero que hace uno es crearse alguna que otra librería justamente con esa funcionalidad que uno acostumbra a usar y de la que el lenguaje que estés usando carece. en definitiva tú mismo estás creando tus propias extensiones.

Básicamente opnio como la mayoría...

... para algunas cosas. En esos casos, salto bruscamente a ASM (incluso mi amado VB6).

Me pasa igual, aunque he usado VB6 mucho profesionalmente a día de hoy, lo uso más por hobby que por otra cosa.

Yo huyo bastante de C y Java, básicamente por que son herederos de Pascal, y no se han 'actualizado' a los tiempos... En tiempos en los que disponer de 4Kb. de memoria era 'el no va más', ahorrar caracteres era primordial, así el hecho de que las sentencias incluyan a diestra y siniestra: '(' ')' '{' '}' en vez de los 'verbosos',  'End loquesea' y ';' en vez de un simple salto de línea y continuar con otra sentencia... implicaba poder escribir código más escueto, más líneas de código en la reducida memoria de entonces, pero lamentablemente a costa de la complejidad para el programador, más errores 'tontos', más tiempo repasando correcciones (innecesarias en otros lenguajes). En aquellos tiempos tenía su lógica, hoy no...

Así que lo que el autor del hilo llama 'acostumbrarse a lo bueno', lo llamo eficiencia y claridad en la redacción del código... al costo de un texto un poco más largo.

Resumiendo... to que me temía, o lo que temíamos muchos...

...que la ambigüedad en la ley, acabe provocando censura preventiva...
¿Es o no, un insulto a la inteligencia?.

Mientras los programadores luchamos contra todo tipo de ambigüedad para evitar errores (de todo tipo), los legisladores llenan los legajos de ellas, para así en los juicios, según convenga poder sostener que sí, que no, o lo contrario, según el signo les interese o hayan 'comprado' al juez del caso... y si la cosa no requiere de un juez, entonces ya ni te cuento...

...algunos usuarios ¿¿¿avanzados??? de Linux (y los hackers de las películas, claro) .... Aunque eso, claro, tenga sus desventajas.

Ya son ganas de perder tiempo. Creo que lo que les pasa es que están más inflados por el ego, que por otra cosa. Sufren el ego de quere que los demás piensen de ellos que están 'fuera de órbita', vamos que son víctimas de su egolatría. Al final no dejan de ser 'fashions victim' de las pelis y series de tv.

La única ventaja claramente reconocible de no usar ratón (para quienes no lo usan), es que ante una eventualidad de que el ratón 'se J0D@', te conoces todos los atajos de teclado, para seguir 'trabajando'... Considernado las posibilidades de que eso ocurra y la frecuencia de ocurrencia es una ventaja tan pobre que solo puedo considerarlo inútil, cerrazón de mente, por simple cabezonería.

Menos mal, que ya no quedan muchos (creo), operadores de tarjetas perforadas... sino a lo mejor todavía habría quien insistiría en seguir usándolas con preferencia incluso a consolas de comandos... tan solo por parecer extravagante a ojos de los demás.

Es interesante que cada programa tenga sus comandos para poder manejarlos al antojo, o poder programar scripts de uso, pero claro, si el destinatario de tales programas son los "usuario domesticus domesticus sofá", me temo que no.
Para ellos cualquier cosa con más de 2 cicks es complicado, se quejan de aprenderse 12-15 contraseñas en sus vidas (no creo que usen más sitios que esos en su quehacer diario), no te cuento ya si encima les tuvieras que obligar a aprenderse de MEMORIA, un par de docenas de comandos por programa.

Luego se quejan los usuarios de Linux, de que el parque PC en el mundo este dominado por Windows y Linux con apenas el 5% (2-3 puntos arriba o abajo), después de casi 3 décadas...

De todos modos, cuando los reconocedores de voz, sean prácticamente infalibles, prácticamente el teclado y el ratón serán opcionales o incluso puede que los sistemas los ignoren (a los fabricantes les gusta los extremos, odian o aman, no tienen término medio ni consideran (puertos extra ante) la posibilidad por si 'algo falla').

En cualquier caso, nunca un sistema de entrada o salida de datos debiera eliminarse por completo, si no dejarlo siempre opcional... si alguien fuera sordomudo, por ejemplo, sería una lástima que ahora una tecnología que es barata, corriendo en los años, luego fuera algo costoso tener que 'fabricarse' un sistema no vocal para poder interaccionar con una interfaz... porque fueron despreciados y deshechados en favor del 'avance tecnológico'...

[ejemplo 1:]

Hola NEBIREEsta propuesta no vale. Estás describiendo un caso muy partícular de bucles "for", los que se parecen /ajustan al patrón de Pascal

Míralo como quieras, el caso es que el compilador al final tiene que reducir cualesquiera sean las expresiones que contiene cada parte a una única salida, sea un valor constante o variable, al final tiene que ser una gramática no ambigua, sino tendría diferentes interpretaciones y desde hace décadas, se conocen algoritmos para descubrir ambigüedades en las gramáticas.

Así puedes encontrar descrito el bucle for en estos o parecidos términos (he omitido las producciones de otras sentencias de iteración que no vienen al caso):
ejemplo 1:
    stmt = for '(' [ assg ] ';' [ expr ] ';' [ assg ] ')' stmt ';'
https://www2.cs.arizona.edu/~debray/Teaching/CSc453/DOCS/cminusminusspec.html

el metasímbolo '[lo que sea]' expresa que es omitible.

ejemplo 2:
    <iteration-statement> ::= for ( {<expression>}? ; {<expression>}? ; {<expression>}? ) <statement> ;
https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm

el metasímbolo: '?' denota 0, 1 o más repeticiones.

Pero en el caso de C que se da, que variables hay?, cual es el valor inicial y/o final?
En C, el bucle for es tan versátil/expresivo como el while.
EScrito de otro modo, en el primer caso hay que explicar por qué el bucle C, acaba:

...para eso existe la especificación de un lenguaje.
Todo lenguaje está descrito en determinados términos, hasta hace poco más de una década la notación BNF (BNF-E), se ha demostrado muy práctica, y más recientemente han salido otros modelos que son simples modificaciones del mismo.
Las especificaciones en prosa ( https://frama-c.com/download/acsl_1.2.pdf (la sección 2.4.2 resulta muy ilustrativa), aunque igualmente muy útiles, rara vez resultan tan claras como las dadas formalmente. Lo usual es que se den ambas al mismo tiempo, la prosa explica los detalles que se dan formalmente.
Así todo lenguaje de programación consta de producciones de hecho cualquier lenguaje de programación se considera una gramática libre de contexto, y se suele resumir en una tupla de 4 elementos...
L = {P, T, R, S)
Donde 'P' son todos los símbolos no terminales, variables o producciones de la gramática.
'T', son los símbolos terminales, tokens, componentes léxicos de la gramática.
'R' son las reglas de producciones, la expresión de todas las producciones.
y 'S' es el símbolo inicial, al que resume todo el lenguaje, esto es que representa: 'pertenece al lenguaje', 'es válido para este lenguaje'...

Se habla de producciones, donde cada producción no es ni más ni menos que la equivalencia resumida (como las dos línea arriba expuestas (son parciales)), a la que luego el analizador sintáctico tendrá que recurrir para determinar si es correcto y se ajusta a la descripción o no. No puede haber ambigüedades, así que tu suposición "hay que explicar por qué el bucle C, acaba", está fuera de toda necesidad de suposición. Aunque los componentes sean omitibles, y el analizador sintáctico lo de por válido luego falta el análisis semántico, que será quien se encargue de revisar lo que no puede ser fijado en reglas o resultan excesivamente complejas o previamente no se dispone de toda la info para determinar sus valores. ...y al caso concreto, un compilador debiera prever el caso de un bucle infinito en situaciones sencillas (esas lo son), o si no está adecuadamente programado, caer en dicho bucle infinito y no llegar a finalizar el análisis sintáctico (caso de derivaciones por la derecha). Lo cual siempre dependerá de la implmenetación de cada compilador en específico, y de la incorrecta interpretación de la especificación del lenguaje o en su defecto de un posible error en la propia especificación.

Ojo: No digo que tu razonamiento falle por lado alguno, tan solo digo, que resulta mucho más simple de entender si se recurre a la especificación del lenguaje. En analizador semántico, (si el sintáctico no está mal programado), debe rellenar tales datos antes o después, de tal modo que cuando le toque analizarlo (al semántico), pueda discernir si es o no un bucle infinito, y la regla se resume en la descripción que dí más arriba. Uno puede darle todas las vueltas que quiera, pero el compilador da solo las necesarias.

...esta piratería a la que nos referimos y que lleva existiendo desde hace casi dos décadas...

Sin duda el autor, o tiene poco más años que esas 2 décadas que dice, o sólo se dedica a la informática desde no más de ese período.
Desde comienzos de los años 80, se viene pirateando el contenido digital... recuerdo muchos amigos intercambiando cintas de casette con juegos del Spectrum, Commodore, Atari, etc... (y no solo juegos también recuerdo empresas pero ellos con programas) así que yo añado 2 décadas más.

El que redacta el artículo, evidentemente no entiende (al menos lo suficiente) el mecanismo de hibernación y parece confundirlo con el de suspensión. Tienen cometidos similares pero ejecución diferente.

Si dejamos el ordenador suspendido o en estado de hibernación, el primer problema que vamos a tener es el consumo de energía. Es mínimo, pero va a existir.

En la suspensión sí, en la hibernación, no. En la hibernación el contenido de la memoria y el estado de la CPU, se guarda a disco, se apaga el sistema y no consume energía. Al ponerlo en marcha de nuevo, se vuelve a cargar todo en memoria y finalmente se restaura el estado de la CPU, para que siga básicamente donde y como se dejó.

La suspensión consume algo de energía, si, pero es un hilillo. El manual de la placa base suele detallar el consumo según el modo de ACPI: os estados

Por otro lado, el disco duro o nuestra unidad SSD van a estar almacenando archivos temporales por los programas en ejecución, para que al encender el ordenador todo vuelva a estar del mismo modo.

Si la hibernación está activa, hay un único archivo temporal, que además está protegido y ocupa el mismo tamaño que tiene la memoria: "hyberfil.sys". Si desactivas la hibernación el fichero desaparece tras el siguiente reinicio. Si se activa ese fichero ocupa dicho espacio (se lo reserva), en todo momento, precisamente para que una posible hibernación no fuere fallida, por falta de espacio.

Es más si la hibernación está activada, aunque no hibernes y simplemente apagues el equipo, dicho archivo sigue ahí... reservando su espacio en disco. El único modo de borrarlo es apagar el equipo habiendo previamente desactivado la hibernación.

Necesitamos apagar o reiniciar, cada cierto tiempo, para que todos esos archivos temporales se borren por completo y el ordenador funcione de manera óptima. En esto, evidentemente, la memoria RAM se ve igualmente perjudicada.

Aquí acierta, excepto en la última frase que habla de la RAM... que no tiene ningún sentido y ni siqueira se molesta en dar 'su razonamiento' si cree tener uno...

Por último, las actualizaciones si lo deseas las puedes activar manualmente... si consideras que es algo ultraurgente que no pueda esperar 4-7 días.

En resumen, eso de que 'es malo suspernder o hibernar el equipo', es una solemne memez, carente de fundamento real.

Considera un poco que es eso de 'rectángulo hueco'... 1,2,3...ya.
Son espacios, luego, hablamos de caracteres... si sabes poner 'x', supongo que también sabrás poner espacios ' ', luego es simplemente una cuestión aritmética de contar 'ovejitas' y 'cabras'...

Resuélvelo con lápiz y papel, luego codifica... intentado ceñirte a como lo has resuelto con lápiz y papel (seguir los pasos).