#19 esos números... ¿no llevan una cantidad excesiva de decimales para estar hablando de personas? 
#125 ¿cuándo empiezas a contar el beneficio? ¿cuando has amortizado la hipoteca, o cuando cuentas todos los gastos de tener una casa cerrada? (ibi, comunidad, etc).
#121 este es un caso que seguro que representa una ínfima cantidad de todas esas compras, pero pensad que:
- Estamos saliendo de 3 años de pandemia donde casi no hemos tenido posibilidad de salir a gastar.
- Si vives en pareja de alquiler, seguramente hayas podido huir de tu capital (Mad/Bcn) y volver una temporada a casa de los padres (y cancelar el alquiler).
- Si antes no tenias claro el tema de comprar por lo caro que estaba todo o porque pensabas que ibas a estar poco tiempo en Madrid, te pueden dar los años y juntarte con la cantidad de pasta necesaria para comprar a tocateja, bien en el pueblo, bien una casa en la capital de las "maluchas" (
#17 There is another chip, and it must be destroyed also.
#77 Ninguna, claro. Pero de cara al cliente (también multinacionales y/o administración pública) .
(Nota a parte: el tema considerar a las empresas por su país me hace gracia -- si es pequeña y solo existe en ese país vale. Pero en cuanto son multinacionales... pierde bastante el sentido. a Indra/Santander/Repsol las consideramos empresas española? Y si trabajas para ellas en su sucursal en un país foráneo?)
#33 o que has estado en empresas MUY rancias. Llevo trabajando en multinacionales tecnológicas 20 años y jamás he ido a trabajar con nada parecido a traje y corbata.
#44 En mi curro estoy acostumbrado a ver de las empresas de mantenimiento a uno, que trabaja para una empresa informática mundial de las grandes, que lo hacen presentarse a hacer cosas en nuestro CPD no en traje pero si con zapatitos, pantalón de pinza, camisa y chaleco. Hablando con él algún día me ha dicho que su vestimenta es para demostrar "seriedad y profesionalidad" y, francamente, yo veo poco profesional que alguien que va a retorcerse en un CPD pasando y tirando cables o moviendo cosas con varios kilos de peso se presente a trabajar vestido de esa manera no acorde con el trabajo que va a hacer.
Es como que querer imponer una estética a los trabajadores sobre su comodidad a la hora de trabajar me parece una forma muy chunga de gestionar el personal.
#77 Ninguna, claro. Pero de cara al cliente (también multinacionales y/o administración pública) .
(Nota a parte: el tema considerar a las empresas por su país me hace gracia -- si es pequeña y solo existe en ese país vale. Pero en cuanto son multinacionales... pierde bastante el sentido. a Indra/Santander/Repsol las consideramos empresas española? Y si trabajas para ellas en su sucursal en un país foráneo?)
#59 Haciendo unos números a vuelapluma :
- El alquiler es aproximadamente 1000e más que en ciudades pequeñas. (Un piso de 500e/mes vale 1,500e/mes). 12,000e al año.
- Seguramente pagues un abono de transporte publico, 100e más al mes.
- La diferencia de coste de vida pueden ser 100/200e más (alimentación, etc), tirando por lo bajo y sin incluir gastos nuevos (distinto tipo de ocio).
Si cuentas lo que te retienen, deberías cobrar al menos ~17,000€ brutos más al año para mantener el mismo nivel de vida que en una ciudad pequeña
#17 cual es el coste de tirar un cable cat6? tiene que ser sustancialmente más barato que comprar cacharros plc+wifi ... y aun asi, a precios similares el cable te va a dar significativamente más alegrías
#23 Lo sé, pero en este caso el factor importante para decidirme entre una solución u otra ha sido la distribución del piso y si implica hacer obra o no, con lo que la solución ganadora fue el uso de PLC, ya que no implica hacerlas, puesto que el medio de transmisión ya está hecho y más que verificado.
#1 pues cada día nos cuesta más encontrar ingenieros de bajo nivel de cualquier tecnología: ni electrónicos, ni programadores ni nada. Estamos acostumbrados a trabajar con abstracciones a alto nivel y cosas que hace 20-30 años eran super básicas ahora son totalmente desconocidas para las nuevas generaciones.
El problema es quién inventará la siguiente generación de microprocesadores (o de cualquier otra tecnología) si ninguno d e los actuales recién graduados está ni remotamente interesado en el proceso, ni se les da los conocimientos para hacerlo.
#4 Interesante punto de vista, aunque discrepo un poco. Con la informática, no sé muy bien por qué, pero sucede mucho un purismo en plan "sólo está bien hecho si es a bajo nivel". Me la voy a ganar pero da igual, es mi opinión. Por ejemplo, le tengo manía a C++, la única ventaja que tiene es la velocidad de ejecución, todo lo demás me parece antediluviano. Si ir más lejos, cada vez que quieres usar una librería de terceros tienes que montar un circo para compilarla y desplegarla. En mi vida me ha tocado usar bibliotecas muy específicas para cálculos matemáticos, algoritmos, etc. y ha sido siempre un horror. Simplemente podemos comparar eigen con scipy para python. Aún no entiendo la manía de definir siempre tipos de datos especiales que hacen lo mismo que un puto integer de 32 bits. Ahora que ya me he quejado, vuelvo al tema. Ensamblador es para el día a día absurdo, impráctico. Como ejercicio para aprender, sin ninguna duda maravilloso, pero con la potencia de cálculo que tiene cualquier chip hoy en día, no hay ninguna razón práctica para usarlo directamente. Además de que un compilador va a optimizar mucho más que tú a mano. Con respecto a lo que comentas de los recién graduados, no es tan importante, el que lo necesite puede aprender despues. ¿Cuántos graduados acaban trabajando en Intel o similares? Cuatro gatos, la mayoría van a hacer web, angular, react o lo que esté de moda en el momento. Dicho de otra forma, como ejercicio teórico-intelectual está genial saber optimizar una caché, cómo funciona un flip-flop o resolver interbloqueos en un sistema operativo. Como aplicación al mercado laboral, no te va a valer para nada. Eso me hace pensar que a lo mejor habría que hacer dos carreras, una más técnica y otra más teórica.
Perdón por el tocho.
#6 Que si, que muy bien trabajar en alto nivel. Yo lo hago. Pero a tu punto de vista le falta lo que apunta #4.
El tema es que a bajo nivel están programados por ejemplo los compiladores, máquinas virtuales o intérpretes. Si nadie estudia seguir desarrollando estos compiladores de bajo nivel, los lenguajes de alto nivel dejan de evolucionar. Y lo que es peor, que para las máquinas (hardware) hace falta conocimientos a un nivel aún más bajo.
No se trata de teoría, también hay práctica. Hay mucho trabajo de esto y es tan necesario como el otro. Otra cosa es que tu vayas a hacer una página web en ensamblador. Eso no lo hace nadie normal, por muy eficiente que pudiera ser.
#10 ... ni por muy deficiente que pueda ser el humano
#10 es más sencillo que eso, incluso. Sin el bajo nivel no puedes hacer un Port de us SO, que te permite cambiar de contexto y hacer el switch de las tareas. Gestión de memoria, pila, Program Counter, acumulador....
Yo trabajé varios años en ensamblador, y llegué a hacer un SO en tiempo real muy simple pero efectivo (todavía está en producción hoy día), Port incluido, para la empresa que trabajaba, en ensamblador y C. Te da una idea muy clara de cómo funciona el proveedor y como optimizar procesos.
#10 no es cierto que los compiladores estén programados en bajo nivel, de hecho hay una fase que suele demostrar la madurez del compilador ( bootstraping )en si mismo que es cuando puedes compilar el codigo de tu compilador usando el mismo.
https://globalwikionline.com/detial/en/Bootstrapping_(compilers)
#57 No puedes traducir de inglés a ruso, sabiendo mucho inglés pero sin tener ni idea de ruso.
Un compilador es un traductor de lenguaje x a código máquina por tanto...
#6 Computer Science vs Computer Engineering vs Information Technology.
#6 No se trata tanto de "sólo está bien hecho si es a bajo nivel", sino de "sólo está bien hecho si quien lo hizo entiende qué pasa a bajo nivel".
Un ejemplo sencillo: uno de los ejercicios de una entrevista de trabajo que hice consistía en convertir una función en javascript que era O(n²) a O(n). La solución que esperaban era obvia, y la saqué correctamente. Pero en realidad seguía siendo O(n²) por el sencillo motivo de que lo que "había que hacer" era utilizar un diccionario para así eliminar uno de los bucles internos. El problema es que, por debajo, un diccionario es, o bien O(n), o bien O(sqrt(n)) según use una lista o un árbol, pero en esa función concreta, en cada pasada podía, o leer un dato, o escribirlo, con lo que si era un árbol, lo que ahorrabas al leer te lo gastabas al balancearlo tras escribir, y si era una lista, estabas igual que antes.
Si no sabes cómo van las cosas "bajo el capó", no te enteras de estos detalles y no entiendes por qué, si has reducido tu función de O(n²) a O(N), sigue tardando más o menos lo mismo.
#20 que es un diccionario? Un Map?
#6 con la potencia de cálculo que tiene cualquier chip hoy en día, no hay ninguna razón práctica para usarlo directamente.
¿La eficiencia, que es la base implícita del existir de toda máquina no es suficiente razón? no es el usarlo directamente, es que usar compiladores que compilen a otro lenguaje, es absurdo, los demás lenguajes son sólo traductores con pérdidas de eficiencia, la IAs generadoras de código harán desaparecer todos los lenguajes que no sean lenguaje máquina, quedando sólo el lenguaje máquina y el lenguaje humano, esto sería lo más lógico.
#6 Tocho perdonado. Y estoy de acuerdo en la conclusión: debería haber diferentes no ya carreras pero sí especialidades, unas centradas en la técnica y otras centradas en el uso práctico del software.
#6 La potencia de cálculo de cualquier procesador de hoy en día es enorme,pero cuando tu software está corriendo, por ejemplo, en una "nube", cada ciclo de ejecución te cuesta dinero. Saber ensamblador te sirve para entender qué código está generando tu compilador del lenguaje X de alto nivel y aprender que construcciones del lenguaje generan código más eficiente para tu problema.
Es un recurso que es para usarlo puntualmente en determinados puntos críticos, pero no está de más saberlo.
#6 hay una cosa que dices con la que no estoy de acuerdo.
No siempre es más rápido el código que genera un compilador que el que puedes hacer a mano.
De hecho , en la libc y la stl de c++ hay código en ensamblador para ciertas funciones.
C y C++ se consideran por muchos como bajo nivel e incluso he oído decir que es ensamblador de alto nivel, al idealizar la máquina.
Pero el tema es que no siquiera c,y c++ llegan a poder abstraerse o idealizar una CPU al 100% por ejemplo las instrucciones vectoriales de una CPU.
Si tuvieras que hacer uso de una convolución en ensamblador x86 hay una instrucción para hacerla vectorizada, sin embargo los compiladores , no son tan inteligentes como para entender que ese bucle es una convolución,(les falta el contexto).
Por otro lado si te apoyas en una librería y compilada , no sabrá si puede alinear los datos en memoria y usar las instrucciones de copia que se introdujo creo que en peintiun IV ...
Hay un papel bastante viejo, que quería comparar c, ensamblador y Pascal, en cuestión de eficiencia, y salía que el codigo más eficiente era el ensamblador después el de c y después el de Pascal.
Pero eso era en la primera versión de código , les pidieron hacer modificaciones al programa , para validar que pasaría en un desarrollo normal.
El de compilador , no solo costaba cada vez más mantenerlo, sino que se fue volviendo más lento y el de c paso a ocupar la primera posición.
Después introdujeron restricciones de tiempo a la hora de poder hacer las modificaciones, es decir les pedían una modificación y solo podían hacerla en x horas, y ahí Pascal también acabo pasando a c.
De aquí se pueden sacar conclusiones, pero una de ellas es que a largo tiempo , si es mejor trabajar en un lenguaje de alto nivel, aunque sea solo porque podremos gastar más tiempo en optimizarlo , pero que ciertas partes del.codigo que sabes que solo se tocaran una vez,o muy muy pocas,pero que se ejecuten continuamente, compensara hacerlo en ensamblador....
Justo lo que hace libc y la stl.
#56 libc y cualquier librería estándar tiene que utilizar un lenguaje de menos nivel porque necesita proveer al lenguaje conviertas funcionalidades como entrada/salida o llamadas al sistema. En C hay trozos de libc en ensamblador como en Python hay trozos de C.
Y el resto creo que te basas en un conocimiento algo anticuado. Hoy en día los compiladores son capaces de reconocer ciertos bucles y convertirlos en instrucciones vectoriales y muchas otras optimizaciones que antes eran impensables. En el 99.9% de los casos el compilador va a generar mejor código ensamblador que un humano para un procesador moderno.
#6 es muy probable que un compilador optimice mas que muchos programadores si te lo compro en parte:
- los programadores los hay muy buenos
- compiladores los hay muy tontos
- muchas veces se programa con clases que son muy genericas que tienen todo tipo de codigo superfluo para el uso que realmente necesitas de esa clase y el compilador eso no te lo optimiza...
- alguien tiene que hacer el compilador que es lo que dice #4, de todas maneras #4 no hacen falta tantos programadores a bajo nivel por lo que no es gran problema que no haya tantos..
#58 Un programador se sabe muchos trucos para optimizar en assembler. Un compilador se los sabe todos. El compilador de ADA hace código máquina que es a la vez más corto y más rápido que el que produce un programador profesional que sabe mucho assembler.
No tengo datos sobre Rust, pero es el camimo hacia el que ir. El potencial es grande pues es el lenguaje donde se le da al compilador más información sobre lo que pretendes hacer.
#94 reconozco que desconozco ADA pero dudo mucho de tu afirmación, por muchas razones pero basta señalar que tu mism@ la mencionas que para que un compilador puedar generar asm optimo debe tener muy claro la intención y c y c++ y ahora Rust son los mejores candidatos por eso mismo. Otra de las razones es que si fueran capaces de hacer algo así con ADA deberian ser capaces con otros lenguajes por que el ADA no tien nada que otros muchos lenguajes no tengan en mayor o menor medida, y solo mencionas ADA. He rebuscado informacion y lo que he encontrado dice lo contrario que el C le da palizas.
"Un programador se sabe muchos trucos para optimizar en assembler. Un compilador se los sabe todos." Imposible optimizar assembler no es solo como traducir una única instruccion de alto nivel a ensamblador, sino un todo un conjunto. Yo te hablo como programador que competía en compaticiones de programacion de demos graficas en de 4 kilobytes maximo, lo programaba en C le decía la compilador que generara el ensamblador y "optimizaba" el ensamblador donde podía...
#6 pero y lo feliz que queda el profesor no teniendo que aprender nada nuevo y con tentando a los 4 frikis intelectuales, eso no lo cuentas
Realmente lo que aprendan en la carrera, los módulos o lo que sea es absurdo, lo único importante es aprender a programar mentalmente luego ya aprenderás los idiomas que quieras, te certificará etc etc
Y esto es como cuando te obligaban a leer los tochos infumables con 16 años, creo que es más fácil enseñar a la gente a programar "cosas bonitas" que motiven que a quien le guste el quijote ya se esfuerza el sólito
#6 Hay una utilidad práctica más, derivada de que mucha gente no opina igual, al menos en parte
En la mayoría de entrevistas que tienen mis estudiantes, haber hecho un juego en ensamblador es un activo muy valorado. La mayoría de ellos me comentan que suele ser lo primero por lo que se interesan y les preguntan. En muchos casos, ha resultado ser motivo de que los contraten.
Y respecto a que ensamblador no se usa, resulta que una proporción no despreciable de estudiantes ha terminado haciendo cosas directamente en ensamblador. Tengo varios de ellos en empresas de robótica programando microcontroladores en ensamblador. Algunos están en nvidia de estancia aprendiendo ensamblador de las tarjetas gráficas. Tengo un grupo en ARM que están optimizando rutinas de multiplicación de matrices. Y, como no podía ser de otra manera, tengo a unos cuantos trabajando en compiladores que se ocupan de diseñar lo que el compilador debe producir como salida. De estos últimos, hay bastantes que están siendo contratados ahora mismo para arquitecturas RISC V, en las que hay mucho que hacer todavía con los compiladores.
El mercado laboral es muy diverso, y las necesidades reales también. No creo que estos trabajos sean los más demandados, pero tampoco son residuales. Son un nicho, como otro cualquiera. Eso sí, un nicho donde se cobra bien, porque cada vez hay menos oferta de trabajadores.
Muy a menudo todos caemos en la trampa de pensar que nuestro entorno de conocimiento es representativo del global. Lo cierto es que siempre hay mucho más allá de lo que conocemos :).
#6 Alguien tiene que saber cómo funcionan los ordenadores, y no usar el framework de moda.
Esta claro que siquieres salir al mercado rápido necesitas usar frameworks que te dan un montón de cosas hechas, pero trabajo con desarrolladores que no saben nada de sistemas, e ingenieros que tienen que decidir que hardware se compra que creen que saben hacer pruebas de rendimiento y no saben.
Mi más cores en un ordenador tiene que ser mejor ni en alto nivel tiene que ser necesariamente más fácil según que tarea. En un grado en informática hay que salir sabiendo lo suficiente de bajo nivel, aunque luego no se vayan a utilizar. Y de todas maneras saber que pasa por debajo ayuda a hacer las cosas mejor.
#80 Ahí tienes razón, lo que me refiero es que hay que tener siempre en cuenta el tiempo de desarollo y usar la tecnología que tenga un balance entre eficiencia, mantenibilidad, facilidad de despliegue, etc. Por ejemplo, en mi vida he visto a mucha gente reinventando la rueda una y otra y otra vez. Si tengo que usar una biblioteca en C++ y para ello necesito un día entero sólo para que compile pues no es práctico. Suele pasar que una librería depende de otra, y esta de otra, etc.
#c-6" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3745089/order/6">#6 Lo que noto de tu comentario es que te dedicas o has estando más en contacto con un tipo particular de desarrollo, y no has salido de ese entorno.
Cada lenguaje tiene un proposito determinado y hay motivos bien fundados en no utilizar lenguajes como java o Go cuando el objetivo es programar tareas de bajo nivel. No es una cuestión de abstracciones, que por supuesto las habrá, pero poner una abstracción no significa que : a) siempre puedas usar esa abstracción y b) se deba dejar de programar o mejorar esas capas inferiores.
Es muy, pero que muy dificil que vayas a encontrar lenguajes de alto nivel, incluso C++, en microcontroladores de cualquier tipo, en sensores, en módulos de procesado GPS, en sistemas de tiempo real, en... En general, por cada usuario que mira una web, el entorno que utiliza tiene al menos 10 veces más dispositivos que han sido programados en C o ensamblador que en lenguajes de alto nivel. Por ejemplo, pensamos en el móvil y solo se nos viene a la cabeza el procesador principal con un ARM o similar... pero se nos olvida que ese cacharro tendrá un microcontorlador para la interfaz usb, otro para la interfaz de red, otro para la wifi, otro para controlar el LCD de la pantalla, otro para el GPS, otro para el procesador de audio, y así un largo etcétera.
Si C sigue siendo uno de los lenguajes más utilizados, no es por casualidad, o por el legacy de los sistemas. Es porque da igual donde miremos, allí habrá al menos 40 o 50 dispositivos electornicos que han sido desarrollados en C. No hay mejor alternativa a día de hoy, y de hecho el uso de C ya es alto nivel para muchos de esots casos. El único lenguaje que podría reemplazarle es rust, pero todavía esta en pañales para poder abordar el reemplazo.
Lo que me pregunto es, como es posible que solo pensemos en páginas web y similares cuando pensamos en programación. Es una visión realmente limitada. La única explicación que se me ocurre es que en España, no hay absolutamente nada de industria técnologica. Si lo hubiese, y tuviesemos que fabricar o diseñar baterías, o sensores de cualquier tipo o... bueno, prácticamente lo que sea, entenderíamos hay mucho, pero que mucho trabajo fuera de los java, go, c# y cia.
#6 me cuelgo de la percha de uno de tus argumentos, y muchas veces, se abusa ya no del JavaScript, sino de Wrappers superiores como Tupeahead. El problema es que, sin conocer básicos de gestión de instrucciones, o memoria, o pila, se puede generar código hipermegaeficiente, sin que el compilador pueda solucionarlo…
Ejemplos:
1/ Uso de fors en lugar de whiles
2/ Tirar de una librería FFT cuando a lo mejor con una pequeña tabla de los valores de 7 senos y cósenos sería suficiente.
Muchos lenguajes de alto nivel dan solo velocidad en el desarrollo, pero un conductor desbocado, sin atenerse a las características del coche y de la vía puede causar una desgracia…
#4 También es cada día más difícil encontrar programadores de alto nivel, tienen más salidas laborales y su vida es más cómoda y sencilla.
Las empresas que diseñan microprocesadores son grandes corporaciones con dinero saliéndoles por las orejas. Que paguen cincuenta mil euros anuales más por programador y que los capten y formen recién salidos de la Universidad
#17 el criterio parece ser:
- Empiezo por los que se van a beneficiar más tiempo de la protección (65 años).
- Luego sigo por los que tienen el sistema inmunitario más debilitado por la edad.
- Si tienes más de 80... ahí te las compongas si se te activa el zoster. (Aunque supongo que puedas comprar tú la vacuna de tu bolsillo, si tienes mucho interés).