Comencé a programar en C ++ en uni y me encantó. En el próximo período cambiamos a VB6 y lo odié.
No podía decir lo que estaba pasando, arrastras un botón a un formulario y el ide escribe el código por ti.
Si bien odiaba la forma en que funcionaba VB, no puedo argumentar que fue más rápido y fácil que hacer lo mismo en C ++, así que puedo ver por qué es un lenguaje popular.
Ahora no estoy llamando a los desarrolladores de VB perezosos solo por decirlo más fácilmente que C ++ y he notado que muchos lenguajes más nuevos están siguiendo esta tendencia como C #.
Esto me lleva a pensar que a medida que más empresas quieren resultados rápidos, más personas programarán de esta manera y, tarde o temprano, no habrá lo que llamamos programación ahora. Los futuros programadores le dirán a la computadora lo que quieren y el compilador escribirá el programa para ellos como en Star Trek.
¿Es solo una opinión poco informada de un programador junior o los programadores se están volviendo más vagos y menos competentes en general?
EDITAR: Muchas respuestas dicen por qué reinventar la rueda y estoy de acuerdo con esto, pero cuando hay ruedas disponibles, las personas no se molestan en aprender a hacer la rueda. Puedo buscar en Google cómo hacer casi cualquier cosa en cualquier idioma y la mitad de los idiomas hacen mucho por ti cuando se trata de depurar, no tienen idea de qué hace el código de cómo solucionar el error.
Así es como me levanto con la teoría de que los programadores se están volviendo más perezosos y menos competentes, ya que a nadie le importa cómo funcionan las cosas, hasta que no es así.
Respuestas:
No, los desarrolladores no se han vuelto más vagos o menos competentes. Sí, existe una necesidad cada vez menor de desarrollo real, en el sentido de que usted lo sabe. Y sí, esto se debe a que las empresas quieren resultados rápidos, y ¿por qué no deberían hacerlo?
Sin embargo, hay un punto final. Siempre habrá necesidad de algunos desarrolladores.
Muchos requisitos son los mismos en diferentes proyectos. El que estás hablando es el código UI. La mayoría de las IU están formadas por un conjunto específico de campos (cuadro de texto, casilla de verificación, radio, selección, etc.) y realmente no tiene sentido desarrollarlos desde cero, una y otra vez. Por lo tanto, se colocan capas de abstracción para eliminar todo ese código repetitivo.
Del mismo modo, la capa de datos, que generalmente no es más que Insertar esto, Eliminar esto, Reemplazar esto y una gran cantidad de vistas diferentes de los mismos datos. ¿Por qué seguir escribiendo eso una y otra vez? Vamos a inventar ORM.
Lo único que debe desarrollar es un código exclusivo de la empresa para la que está desarrollando.
Pero siempre habrá esa singularidad, donde no la hay, hay una oportunidad de negocio, y siempre habrá una necesidad de que las personas escriban código.
Dicho todo esto, también tenga en cuenta que ser desarrollador es mucho más que escribir código. Ya sea que esté codificando en ensamblaje puro o uniendo componentes de Drupal para crear un sitio basado en contenido, está traduciendo la necesidad comercial en algo que la computadora entienda.
La parte más importante de ser un desarrollador de software es poder comprender el requisito comercial lo suficientemente bien como para explicarlo a la computadora.
Realmente no importa qué idioma estés usando para explicarle cosas a la computadora, solo importa que puedas. Y este es un trabajo duro, nada vago al respecto.
fuente
¿Es un mecánico perezoso y menos competente porque está usando una llave hidráulica ?
Imagen dos chicos, digamos Brad y Pete. Ambos trabajan en dos garajes cambiando neumáticos diariamente. Brad es un tipo inteligente, sabe que usar mejores herramientas puede hacer su trabajo mejor y más rápido. Usar la llave hidráulica lo ayuda a cambiar más neumáticos. Los clientes esperan en una fila más corta: todos están contentos. Bard también sabe que esta llave es a veces demasiado grande y no puede ayudarlo con diferentes tipos de tornillos.
Por otro lado, Pete dice que la llave hidráulica es una blasfemia y que Brad no es un "mecánico real". Claro que Pete solo puede hacer la mitad de lo que hace Brad, pero lo hace de la "manera correcta".
¿Qué piensas, qué clientes de garaje elegirían? Uno que tome 20 minutos o uno con 40 minutos de espera.
Es bastante similar con la programación. C ++ es un buen lenguaje y tiene su propósito (principalmente rendimiento). Lo que me gusta de los lenguajes como C # es que puedo concentrarme en un problema, pensar en el algoritmo sin todo el ruido que hace C ++, como advertencias ambiguas del compilador, comportamientos indefinidos, etc. El desarrollo se está volviendo cada vez más complicado que en los viejos tiempos de los mainframes y las primeras PC, sin embargo, el cerebro humano sigue siendo el mismo, bastante tonto. Una aplicación puede ejecutarse en la nube, móvil, escritorio, hay muchas dependencias, problemas de seguridad y otros problemas. Quiero tener una mejor herramienta para enfocarme en problemas más complicados y resolverlos.
Use mejores herramientas para hacer el trabajo, no tiene nada de malo.
fuente
Entonces, ¿a qué llamamos programación ahora?
Tu dices:
solo haz un experimento: mira Star Trek e intenta interpretar las cosas que la computadora tiene que hacer un poco 'sin gracia'.
Cuando llama a Programación: 'Conocer el uso de la memoria, punteros, etc.', sí, supongo que será menos importante (ya que 'Conocer http, openid, unicode' se volverá más importante).
Pero, en mi opinión, todo es 'complejidad accidental', y el verdadero trabajo como programador es 'hacer que las máquinas de construcción resuelvan problemas, asegurándose de que uno entienda lo suficiente de los problemas accidentales para lograr la tarea' y, por esa definición, alguien conversando con una computadora star trek necesita ser un programador (es decir, tener las mismas virtudes que ahora).
fuente
Los programadores no se vuelven más perezosos. Los programadores siempre han sido flojos. Ser perezoso es parte de la naturaleza fundamental del trabajo. El problema es que la gente asume que ser flojo es negativo. Ser un programador "vago" es una virtud.
Recuerde el viejo adagio, "Trabaja de manera más inteligente, no más duro". Este es el impulso fundamental de los programadores.
Los chicos que construyeron y programaron las primeras computadoras no lo hicieron porque les gustaba trabajar duro, lo hicieron para EVITAR el trabajo aún más difícil. (haciendo páginas de cálculos a mano)
Ser 'perezoso' es una de las razones fundamentales por las que los programadores programan. Es por eso que escribimos lenguajes nuevos y cada vez más altos, mejores y mejores depuradores e IDE, scripts de shell y construcción, etc.
Un programador observa un problema, cualquier cosa que hace o piensa;
"¿Puedo automatizar esto?" , "¿cuánto tiempo tomaría eso?" , "¿cuánto tiempo me ahorraría eso?"
Hacemos esto porque somos flojos, no queremos hacer una tarea repetitiva y aburrida cuando podríamos estar haciendo cosas que son mucho más divertidas.
Si los programadores no fueran perezosos, ningún programador habría visto la necesidad de escribir un solo nuevo lenguaje o compilador.
En cuanto a la noción de que un programador es "vago" porque tiene que "buscar cosas", ¿a quién le importa? La suposición de que es más trabajo aprender cada matiz de un idioma en particular (y nunca tener que buscar algo) es encontrar y usar lo que necesita cuando lo necesita es una falacia. Además, el proceso de buscar cosas es el proceso de aprendizaje y la razón por la que existen sitios como este.
Si alguien quiere un trabajo duro de programación, les diría que vayan a codificar a mano algún código de máquina en hexadecimal. Hecho eso? ¿Quieres algo más difícil? Ahora ve a depurarlo.
fuente
En primer lugar, llamar perezoso a las personas que usan, por ejemplo, idiomas con recolector de basura, es como llamar perezoso a las personas que conducen automóviles con transmisión automática. OMI es un poco ridículo.
En cuanto a la competencia, la programación es un trabajo mucho más popular e igualitario que solía ser. Entonces, sí, hay muchos recién llegados que carecen de conocimiento. Sin embargo, no quiero decir que de repente haya programadores menos competentes. De hecho hay más. Solo estás mirando el lado equivocado de la curva de la campana.
fuente
Me siento tentado a decir: "sí, los programadores junior no informados y obstinados se han vuelto perezosos y menos competentes", pero intentemos una respuesta seria:
Muchas cosas se han vuelto más fáciles, pero se espera más de nosotros. Actualmente estoy creando una aplicación web que tiene muchas características que generalmente se encuentran en aplicaciones GUI bien hechas (vistas con pestañas, cuadrículas editables y ordenables, exportación de Excel, etc.). Las herramientas que estoy usando (ExtJS, etc.) hacen que sea razonablemente económico crear una aplicación de este tipo.
Hace diez años, habría sido casi imposible, al menos muy costoso, crear una aplicación de este tipo. Pero hace diez años, un simple formulario HTML con una tabla HTML habría sido suficiente para los clientes. Hoy, con el mismo esfuerzo, son posibles mejores (al menos más hermosos) resultados, ¡y los clientes esperan obtenerlos!
En general, un desarrollador de software de hoy necesita saber más idiomas que un desarrollador de software hace 20 años. En aquel entonces, algo como C y SQL eran suficientes. Hoy, estoy usando JavaScript, HTML, Groovy, Java, SQL, todo en el mismo proyecto.
fuente
Los programadores se están volviendo menos competentes y más perezosos en algunos aspectos, pero más competentes en otros, aunque la división C ++ / VB no es la razón o un síntoma en mi mente.
El uso de un generador de GUI no es perezoso, es simplemente diferente, se trata de herramientas para el trabajo en cuestión. Si un programador de ensamblador llamara flojo a un programador de C ++, llamaría mentira sobre eso (correctamente) y lo mismo es cierto para C ++ y VB. VB le permite hacer algunas cosas rápidamente a expensas de cierto control. Las barreras para comenzar a codificar en él son ciertamente más bajas, pero eso es algo muy diferente a la pereza: solo aprende diferentes cosas y las aplica de diferentes maneras. Los programadores de VB no son más vagos que los programadores de C ++ son improductivos, simplemente trabajan y producen de diferentes maneras.
En el punto más amplio, generalmente la educación de los programadores es mejor ahora que nunca. La idea de no usar el control de código fuente, por ejemplo, es bastante aborrecible para casi todo el mundo donde hace 10 o 20 años eso no hubiera sido tan cierto. Del mismo modo, es más probable que comprendan y quieran utilizar pruebas unitarias automatizadas, integración continua, etc., en ese sentido, son más competentes de lo que eran.
Pero lo que creo que ha cambiado es que las personas ya no saben cómo resolver problemas de la forma en que solían hacerlo, y eso es cierto en casi cualquier lenguaje convencional. La respuesta instantánea a cualquier problema ahora es Google y, si bien es excelente y funciona el 95% del tiempo, veo demasiados programadores que no tienen idea de qué hacer cuando no es así.
No es que no entiendan los fundamentos (no lo hacen, pero eso no es realmente un gran problema), es que no pueden resolver los problemas de tal manera que incluso puedan resolver qué fundamentos necesitan estar familiarizándose con
Antes de Google no tenías otra opción. Sus recursos fueron su equipo, unas pocas docenas de libros físicos a los que podría tener acceso y su cerebro. Esa configuración significa que si encuentra un problema, es probable que lo esté resolviendo usted mismo desde algo cercano a los primeros directores, por lo que se volvió bastante bueno o se quedó sin trabajo rápidamente.
Y esto era cierto independientemente del idioma que usaras. VB es de alto nivel y se esconde mucho, pero eso significa que cuando se trata de resolver problemas, eso realmente significaba que había más cosas por las que tenía que estar trabajando. Si algo no funcionaba, tenía que ser más creativo y trabajar más duro ya que tenía menos control. Como programador de VB (y hablo por experiencia) no sabías menos que los chicos de C ++, solo sabías cosas diferentes pero ambos sabían cómo resolver problemas.
Pero probablemente sea duro verlo como una crítica significativa de los programadores en estos días, no desarrollan las habilidades porque no las necesitan, pero es una debilidad en comparación con aquellos que adquirieron las habilidades de cuando eran necesarias.
fuente
Noto en tu perfil que tienes 23 años. Déjame poner mis dientes en blanco y darte una perspectiva de alguien de aproximadamente el doble de tu edad que ha estado haciendo esto durante mucho tiempo:
Solía ser que había mucho menos de todo, comenzando con la potencia informática, el almacenamiento y el ancho de banda de la red, si es que tenía una red. Esas escaseces ponen límites a lo que podría hacer razonablemente, lo que hace que sea mucho más fácil comprender todo. El software que ejecutamos hoy es mucho más capaz que las cosas con las que trabajé hace 25 o 30 años, y esas capacidades significan que hay mucho más. Eso hace que reunir una comprensión detallada de todo sea mucho más difícil para una persona. Parte de eso tiene que ver con el hecho de que las cosas seguirán aumentando en complejidad y parte tiene que ver con los efectos secundarios de la edad.
El ecosistema informático se está volviendo muy parecido a los sistemas biológicos: los humanos son más complejos que los organismos unicelulares, y partes de nosotros tenemos que especializarnos si vamos a hacer algo bueno. Mis células cerebrales son muy buenas para las cosas cerebrales, pero se perderían si se introdujeran en mi riñón y se espera que hagan cosas renales. Del mismo modo, el tipo que es bueno escribiendo procesadores de señal digital podría no tener idea de cómo funciona la indexación de texto completo, porque esa no es su especialidad. Pero ambos podrían evolucionar un poco y aprender a entenderlo si fuera necesario, pero hay límites en cuanto a la distancia en la que puede extenderse y ser efectivo en lo que hace.
Cuando tiene un trabajo que hacer, a menudo tiene que dar el salto de fe de que una herramienta que está utilizando (biblioteca, RDBMS, subsistema completo, etc.) funciona como debería. Una de las cosas que trae la experiencia es la capacidad de elegir qué agujeros de conejo vas a correr para descubrir fallas en tus herramientas, solucionar el problema y luego volver a lo que estabas haciendo.
Eso es todo una cuestión de perspectiva. Estuve cerca de ver que C ++ surgió, y también sigue esa tendencia. C ++ hace las cosas mucho más fáciles que C hace, C hace las cosas mucho más fáciles que el ensamblaje y el ensamblaje hace las cosas mucho más fáciles que escribir códigos de operación manualmente. Como alguien que ha escrito mucho ensamblaje y ensamblado algunas cosas a mano desde cero, eso lo pondría, como programador de C ++, tres pasos por el camino "es más fácil".
fuente
Algo que he mantenido durante mucho tiempo ahora es:
Cuando enseñé a programar el primer ejercicio, el primer día de clase fue cómo construir una aplicación en NOTEPAD y compilarla usando VCC o VBC. Sí, estas son cosas que nosotros (como programadores) no hacemos a diario, pero debemos entender lo que sucede cuando presionamos "F6".
Los programadores no (en general) se están volviendo "más perezosos" tanto como esperamos obtener más de nuestras herramientas. No necesito escribir "get / set" 10,000 veces al día, ME GUSTA que Visual Studio y otras herramientas como Code Smith y Resharper trabajen para que yo haga lo que ya sé hacer para poder aplicar mi esfuerzo a calcular cómo hacer cosas "nuevas". Eso no me hace más vago, me hace "innovador".
Como desarrollador profesional, no deberíamos estar 'perdiendo el tiempo' reinventando la rueda, pero debemos entender claramente lo que implica hacer la rueda que vamos a utilizar. Estas son cosas que 'deberíamos' aprender como desarrolladores de estudiantes (pero desafortunadamente, a menudo no lo estamos). Si un desarrollador no comprende alguna tecnología de "caja negra", eso realmente los hace menos "competentes". La mayoría de los desarrolladores solo 'básicamente entienden' cómo funciona un controlador ODBC, simplemente entienden 'qué' hace. ¿Tengo que saber cómo funciona una transmisión para ser un conductor competente? Yo diría que no. ¿Me hace un dueño de automóvil más competente saber esto, sí?
fuente
La necesidad de un desarrollo rápido de aplicaciones (enlace wiki obligatorio: http://en.wikipedia.org/wiki/Rapid_application_development ) ha significado que los desarrolladores escriban menos código y los desarrolladores más nuevos entiendan menos, porque no necesitan entender cómo implementar un lista vinculada ya que tienen algo más de alto nivel para enfocarse.
No puedo atrapar, matar, desollar, desmenuzar y curar carne, y dudo que el tipo del café de abajo pueda, pero aún así obtengo mi sándwich de tocino, al igual que los hombres de negocios obtienen sus aplicaciones de desarrolladores que no saben punteros (como yo!)
fuente
Un buen desarrollador de software no es uno que reinventa la rueda. Él puede usar las herramientas que se han construido antes que él. No pierde el tiempo reescribiendo las mismas viejas y aburridas cosas, que se han escrito cientos de veces, se vuelve aburrido rápidamente y probablemente ya exista en una versión de mayor calidad.
Si les da un lenguaje que ya tiene discos de piedra redondos agrupados, es muy probable que no pasen demasiado tiempo reinventando las ruedas. Si obtuviera un centavo por cada rutina de copia de cadena escrita en C, probablemente podría comprar toda la industria del software.
La pereza es, de hecho, una de las tres grandes virtudes de un programador. Las herramientas de las que habla fueron creadas por buenos programadores para buenos programadores, para reducir la redundancia y el aburrimiento y, por lo tanto, aumentar la productividad y la motivación. De hecho, tales herramientas pueden tener efectos negativos en los principiantes, ya que inhiben una comprensión más profunda del aspecto de programación que simplifican.
fuente
No. Solo te estás haciendo viejo.
No es broma, lo que estás experimentando es una especie de derecho de paso para los desarrolladores. Ha sido desde los primeros idiomas de nivel superior suplantado ensamblado En aquel entonces, habrías escuchado a todos los programadores de ASM quejándose de lo mismo. Dentro de cinco años, todos los desarrolladores de Ruby on Rails se quejarán de lo flojo que está siendo otro grupo de nuevas herramientas que están haciendo que la gente.
Este estribillo se repetirá hasta que las máquinas nos destruyan a todos: "¿Parece que la tecnología X está haciendo que los desarrolladores sean más flojos y peores que la tecnología Z que siempre he usado?"
La buena noticia es que, a pesar de que los compiladores han recorrido un largo camino, la gente todavía necesita ensamblar y C y todos los otros viejos incondicionales para muchas cosas ... pero no la mayoría de la innovación tecnológica de vanguardia. Si quieres estar a la vanguardia, te sugiero que actualices tu conjunto de habilidades.
fuente
Desde mi experiencia, sí y no, pero no es culpa de los idiomas; es culpa de los propios desarrolladores. He trabajado con muchos desarrolladores a los que no les importaba hacer las cosas bien, mejorarse a sí mismos o realmente hacer otra cosa que producir la misma basura que han hecho durante años. Intentar que estas personas mejoren es como hablar con un muro de ladrillos: la mitad de las veces ignoran cualquier cosa que no hayan usado en el pasado o que no estén dispuestos a "arriesgarse" con algo que pueda mejorar su productividad. .
Los lenguajes más avanzados no son el problema, son los programadores los que no tratan esta profesión como un oficio en constante evolución. No tiene que ser íntimamente consciente de todo lo nuevo, o subirse a cada nuevo carro, pero al menos debe intentar mejorar en lo que hace.
Para un ejemplo concreto: soy un desarrollador .NET de oficio. Esperaría que un desarrollador competente de .NET conozca cosas como LINQ, Entity Framework, WPF, MVC y similares; no tienen que haberlo usado, o estar empujándolo en el lugar de trabajo, pero al menos una comprensión pasajera de "Esto existe" es mejor que la absoluta ignorancia que veo con demasiada frecuencia.
fuente
Solo he estado codificando durante aproximadamente 4 años en el trabajo ahora y eso ha sido casi completamente C #. Aprendí C ++ cuando estaba en la universidad y Uni, pero no podría hacer mucho con eso ahora.
Por lo tanto, para el desarrollo de la GUI, podría verse como vago, pero nuevamente, no podría verse que puede centrarse menos en codificar esa parte y más en desarrollar la lógica de la aplicación en sí.
así que quizás, en lugar de volverse menos competentes, están moviendo el foco, probablemente mucho hacia sistemas de comunicación y distribuidos, por ejemplo, computación en la nube y SOA. Aunque esto también podría ser un pensamiento similar de un programador intermedio.
fuente
Probablemente sea cierto que la barrera de entrada en los trabajos de programación se ha reducido cada año. Por ejemplo, ahora es posible que los ingenieros cuya especialidad no sea principalmente software y artistas escriban código usando lenguajes de script.
Esto implica que el nivel de competencia realmente ha aumentado, si se considera la amplitud. Que los artistas puedan programar también significa que ahora hay más programadores con habilidades artísticas.
fuente
Hay una diferencia entre "programador" y "programador real". No llame a HTML un lenguaje de programación, pero hay muchos "programadores HTML". Cada uno de ustedes (programadores / desarrolladores) puede hacer una experiencia con sus colegas: simplemente "apague Internet (en realidad no les permite usar motores de búsqueda)", y verá que una gran variedad de "programadores" se sentarán sin trabajo. ¿Qué pueden hacer? ¿Saben que si necesitan, por ejemplo, buscar texto, deberían "buscar 'búsqueda de texto en% language_name%'"? No pueden responder a esto: ¿cuáles son las diferencias en los algoritmos de Boyer-Moore y Knuth-Morris-Pratt?
Entonces, IMO, programar significa resolver problemas, sabiendo muy bien como mínimo un lenguaje de programación con su 'STL' y otras cosas importantes. La programación es un arte, es un tipo de vida, eso no es algo que todos puedan hacer.
Perdón por más sarcasmo del necesario, pero creo que este artículo dice mejor que yo.
¿Me equivoco?
UPD: Lo principal e importante es el conocimiento de los fundamentos, como algoritmos, estructuras de datos, etc. ¿Cuántos de ustedes pueden implementar las bibliotecas / funciones estándar / etc. en caso de que hoy se eliminen accidentalmente? En mi opinión, el programador debe usar código 'alienígena' desarrollado / bien depurado (bibliotecas / frameworks / etc.), ¡pero siempre debe poder reinventar la rueda!
fuente
En cuanto a que VB es fácil de usar, y los programadores perezosos eligen VB por eso:
Creo que VB está rodeado por un gran mito de ser fácil de usar. Este mito era originalmente cierto: en los días alrededor de 1991-1994, cuando los dinosaurios caminaron por la tierra, solo había dos herramientas RAD reales, VB y Delphi. Eran bastante similares, pero TEN EN CUENTA: ¡Delphi y VB fueron igualmente fáciles de usar! La única diferencia notable entre ellos fue que VB tenía una sintaxis completamente ilógica y producía programas increíblemente lentos.
Las GUI de C / C ++ se escribieron en MFC o en Win API sin procesar. Por lo tanto, VB fue ciertamente más fácil de usar que la alternativa de Microsoft. Entonces la rumorología fue así:
Este rumor continuó, a pesar de que Delphi siempre fue igualmente fácil, si no más fácil, ya que Pascal es un lenguaje lógico y cuerdo.
Luego, a finales de los años 90, Borland lanzó un equivalente en C ++ a Delphi: C ++ Builder. Ahora había 3 herramientas igualmente fáciles. Alrededor de este tiempo, los pocos argumentos racionales restantes para usar VB murieron. Sin embargo, el mito siguió vivo. "VB es el más fácil".
Luego apareció Java y también había varias herramientas RAD para él (y para su versión fiasco de Microsoft llamada J ++). Sin embargo, el mito VB perduró.
Luego, Microsoft también hizo soporte RAD para C ++, y también ideó C #, convirtiéndolo todo en una gran sustancia llamada .NET. Como el mito de VB aún perduraba, pudieron engañar a los antiguos desarrolladores de VB para que usaran VB.NET en lugar de C ++ o C #. Aunque VB.NET era bastante incompatible con versiones anteriores de VB.
Hoy, VB es un lenguaje completamente redundante. La herramienta RAD no es más fácil que cualquier otra herramienta RAD. La sintaxis del lenguaje es francamente horrible, tan mala que en realidad fomenta el mal diseño del programa y la mala práctica de la programación.
fuente
Hay una gran variedad de actividades que se agrupan bajo la bandera de "programación", y un número cada vez mayor de trabajadores involucrados en el extremo "técnico" de la escala. No necesita ser capaz de escribir compiladores, o incluso seleccionar entre un conjunto de algoritmos para resolver un problema particular para armar un sitio web en PHP. La industria / sociedad necesita mucha gente que produzca dichos sitios web (aparentemente), y también un cierto número de programadores que trabajan en problemas más difíciles. Ese segundo grupo no es perezoso o incompetente en su conjunto, o nuestros aviones se incendiarían, los cajeros automáticos que entregan cantidades aleatorias de efectivo, las máquinas de rayos X que administran dosis fatales de radiación, los mercados financieros se vuelven locos, etc. Esperen, olviden sobre el último :-)
fuente
Un lado de esto que creo que todas las otras respuestas solo están mirando es que esta es solo la tendencia generalizada que va de los idiomas de bajo nivel a los idiomas de alto nivel.
Sí, la industria del software está cambiando de lenguajes de bajo nivel a lenguajes de alto nivel, siempre lo ha hecho, y probablemente continuará haciéndolo mientras creamos mejores herramientas. Sí, esto podría considerarse perezoso, ya que tenía que trabajar muy duro para hacer cosas que son básicas para el estándar actual. Pero no diría menos competente. La competencia es simplemente pasar de la implementación al diseño.
Nivel bajo Es algo subjetivo, pero a un nivel bajo, está trabajando más cerca del hardware. Hay menos asimiento de la mano y suposiciones de intención. Se presentan las herramientas básicas y el programador deja las cosas hechas. Los idiomas de bajo nivel llegaron primero, por supuesto, y generalmente son las herramientas de la vieja guardia, ya que los idiomas de alto nivel no existían cuando comenzaron. Siempre habrá un desarrollo de bajo nivel. Pero no haría un sitio web en asamblea.
Nivel alto El objetivo a niveles altos es automatizar la funcionalidad básica y simplificar la programación. Reduce la barra de entrada para los nuevos programadores, hace las cosas más rápido y estandariza cómo representamos y procesamos los datos, a menudo con una sobrecarga. Considera una cuerda. En los primeros días, alguien probablemente usó 1-26 para az, y usó solo 5 bits y solo tenía que saber de qué tamaño eran sus palabras. Luego se desarrolló el estándar ASCII y teníamos cadenas C con un carácter terminador. Ahora tenemos objetos que manejan cosas para evitar desbordamientos de búfer y subtipos especiales que no permiten caracteres de escape. O un bucle. Un ciclo "for" es un nivel ligeramente más alto que un ciclo "while". Y un bucle "while" es realmente una representación de una forma estructurada de llamar a GOTO.
También,
¡Bienvenido al futuro! Eso es exactamente lo que hacen los compiladores. En los viejos tiempos la gente tenía que escribir el código de la máquina a mano. Ahora lo hemos automatizado y simplemente le decimos a la computadora cómo nos escribe el código de la máquina.
fuente
Creo que en algún momento del camino perdiste de vista lo que a los programadores se les paga por hacer.
Nuestro producto no es Code, es un software que funciona.
No estamos construyendo muebles donde las colas de milano cortadas a mano de alguna manera impartan un valor extra debido a toda la "artesanía" manual que se utilizó en ellas.
Nos pagan para resolver problemas comerciales en las computadoras). Si puede entregar el mismo producto en menos tiempo por menos dinero, entonces creo que es nuestra OBLIGACIÓN dejar de fingir que los programas C ++ son superiores simplemente porque son más complejos de construir.
fuente
La proporción de (desarrolladores de programas principales / recuento de desarrolladores) está disminuyendo porque:
Las herramientas se están volviendo más fáciles, esto significa que se necesita menos talento para el mismo problema
La gente se está acostumbrando a las tecnologías de TI, esto tiene más ganas de gastar dinero en herramientas personalizadas
La literatura de Ciencias de la Computación está creciendo exponencialmente, la especialización y la división del trabajo están aumentando, por lo que no hay más personas "Aristóteles" que hablen de todo (en realidad no necesitan saberlo todo debido a las capas de abstracción)
Se ofrecen más trabajos, se afloja el filtro
Se necesita más automatización en cada ciclo de vida, la demanda está aumentando y la oferta no es suficiente
La proporción de desarrolladores a la población está aumentando.
Entonces, la gente no se está volviendo más perezosa y menos competente, el promedio cae porque la informática es un área más abierta ahora.
fuente
Está socavando todo su punto por el hecho de que de alguna manera, las ruedas aún se fabrican. Entiendo su punto de vista, pero me he dado cuenta de que en cualquier disciplina, hay suficientes personas interesadas en las cosas de bajo nivel para mantener eso en marcha. Por ejemplo, uso Qt para construir GUI. Esa herramienta no llegó por arte de magia, la gente desarrolló el vínculo entre las cosas de bajo nivel y las cosas que hago. ¿Menos personas entienden las cosas de bajo nivel, sí? Menos personas también pueden matar su propia comida o arreglar su propio automóvil, pero la sociedad se las arregla para sobrevivir.
fuente
Antes de la década de 1940 las computadoras eran circuitos cableados. Luego, a Von Neuman se le ocurrió la idea de ubicaciones de memoria almacenada. Estoy seguro de que esos programadores del MIT pensaron que iba a degradar su comercio en algo demasiado fácil. Luego vino la asamblea, luego vino FORTRAN, luego ada, luego C, luego c ++, luego java y así sucesivamente. El punto es, el punto de un lenguaje es permitir una abstracción más y más. Ese siempre ha sido el objetivo y es la razón por la que C ++ se puso al día y luego Java después. Mi mayor problema es que las universidades ya no enseñan a los estudiantes nada sobre computadoras. No contrato a programadores de C # si no conocen C ++ como el dorso de su propia mano. ¿Por qué? Porque es demasiado fácil ser un mal programador cuanto más abstracto se vuelve el lenguaje. Necesitan comprender punteros, gestión de memoria, enlace dinámico, etc. . por dentro y por fuera antes de que puedan entender C # al nivel en el que confío en que contribuyan a nuestra base de código. También hago que luchen por crear archivos antes de permitirles usar Visual Studio. Dicho esto, me encanta C # y un buen IDE, pero son buenos como herramientas cuando se entienden correctamente. En mi opinión, una abstracción es más útil cuando entiendes los detalles que se están abstrayendo; esa es una idea muy antigua, ver a Tomás de Aquino sobre la relación de la abstracción con los detalles.
Creo que otro buen ejercicio para los desarrolladores de nivel de entrada es hacer que escriban algunas aplicaciones utilizando la API de Windows. Luego, después de que lo terminen, pídales que lo orienten a objetos donde cada formulario herede de su clase de ventana genérica. Pídales que encapsulen el bucle de eventos y coloquen algunos punteros de función que vuelvan a su clase de formulario. Entonces diga buen trabajo, Microsoft ya lo hizo por usted, se llama System.Windows.Forms. Que te diviertas.
Si van a ser desarrolladores web, pídales que escriban algunos programas CGI para que comprendan la POST, GET, etc ... y luego escriban la página. Hace que ASP.NET y PHP tengan mucho más sentido.
Si están trabajando en algo de nivel inferior en una red, haga que escriban algunas aplicaciones usando sockets antes de presentarles las bibliotecas que ya lo han hecho.
Descubrí que esto mejora la productividad a largo plazo porque les brinda las herramientas y las intuiciones correctas para resolver sus propios problemas.
Se supone que las universidades están haciendo esto, pero no lo son, así que tenemos que hacerlo.
Dicho esto, estoy de acuerdo en que cada vez es más difícil encontrar programadores a los que valga la pena salir de la universidad, principalmente porque no fueron eliminados al verse obligados a escribir algoritmos recursivos y listas vinculadas. Además, por lo general, solo han tenido cursos Java o .NET y, por lo tanto, no entienden nada sobre su forma de trabajar. Aún así, la abstracción es bastante útil cuando se usa correctamente.
fuente
No estoy de acuerdo con este punto.
Sin saber qué es la conciencia, el trabajo del programador es seguro.
Así es como se ven las "máquinas pensantes" en este momento:
Creo que solo aquellos programadores que no entienden este punto están condenados.
Por ejemplo, la respuesta del deshumanizador :
Y con "este punto" quiero decir, es incorrecto intentar superar a la computadora en lo que son mejores: algoritmos. En cambio, se supone que el programador está ayudando a la computadora con el contexto, contando los problemas que estamos tratando de resolver.
Las herramientas en sí mismas no solucionan problemas, solo (a veces) hacen que los programadores sean más eficientes.
Es como con: "las armas no matan, los humanos sí".
fuente
Absolutamente no. En mi experiencia, el uso de las herramientas de desarrollo correctas permite el desarrollo rápido de aplicaciones sin sacrificar la calidad. De hecho, diría que, en su mayor parte, la calidad ha aumentado debido a nuestra "excesiva dependencia de las herramientas". Además, las herramientas de desarrollo pueden disminuir la curva de aprendizaje e introducir a más personas en la programación. Esto, por supuesto, tiene un inconveniente, ya que hay muchos más programadores novatos, pero en general, ayuda en el proceso creativo y empuja la tecnología hacia adelante.
fuente
En términos generales, 'No'; Pero hay una gran advertencia.
Si, de hecho. Su experiencia en la universidad habla de la misma advertencia que mencioné.
Si no sabe qué problema está resolviendo su herramienta, o es incapaz de solucionar problemas cuando su herramienta tiene problemas propios, entonces es una gran señal de alerta. Esta circunstancia no implica necesariamente pereza, pero probablemente implica inexperiencia.
fuente
Creo que hay 2 sabores de programadores. Hay programadores que simplemente programan para hacer el trabajo debido quizás a una fecha límite o tal vez solo para ser más productivos. Yo diría que eran flojos. Simplemente creo que no les interesa "cómo" una computadora hace lo que hace o "cómo" un programa hace lo que hace.
Luego están los programadores apasionados, como yo. Los programadores apasionados, como yo, quieren saber exactamente qué está pasando en la CPU. Al igual que un buen psicólogo intenta descubrir qué está sucediendo en la cabeza humana, los progcólogos, como yo, quieren saber qué está sucediendo dentro de la CPU. Entonces aprendemos, diseccionamos y analizamos un programa y utilizamos herramientas, como Reflector y desensambladores, para tratar de descubrir cómo funciona un programa.
fuente
Tengo una esperanza silenciosa de que las cosas cambien. Las CPU no están escalando tanto verticalmente, solo horizontalmente, y ARM, etc. tendrán recursos limitados en el futuro cercano.
Es muy posible que disminuya la demanda de programación sin arrastrar y soltar y veremos algunos trabajos más interesantes.
fuente