¿Linq está teniendo un efecto entumecedor en los programadores .NET?

Muchos de nosotros comenzamos a ver este fenómeno con jQuery hace aproximadamente un año cuando la gente comenzó a preguntar cómo hacer cosas absolutamente locas como recuperar la cadena de consulta con jQuery . La diferencia entre la biblioteca (jQuery) y el lenguaje (JavaScript) aparentemente se pierde en muchos programadores, y da como resultado que se escriba mucho código inapropiado y complicado donde no es necesario.

Tal vez sea solo mi imaginación, pero juro que estoy empezando a ver un aumento en la cantidad de preguntas en las que las personas piden hacer cosas igualmente locas con Linq, como buscar rangos en una matriz ordenada . No puedo superar cuán completamente inapropiadas son las extensiones de Linq para resolver ese problema, pero lo más importante es el hecho de que el autor simplemente asumió que la solución ideal involucraría a Linq sin pensar realmente en ello (por lo que puedo decir). Parece que estamos repitiendo la historia, generando una nueva generación de programadores .NET que no pueden distinguir la diferencia entre el lenguaje (C # / VB.NET) y la biblioteca (Linq).

¿Qué es responsable de este fenómeno? ¿Es solo bombo? Tendencias de urraca? ¿Linq se ha ganado la reputación de ser una forma de magia, en la que en lugar de escribir un código solo tienes que pronunciar el encantamiento correcto? Apenas estoy satisfecho con esas explicaciones, pero realmente no puedo pensar en otra cosa.

Más importante aún, ¿es realmente un problema, y ​​si es así, cuál es la mejor manera de ayudar a iluminar a estas personas?

Básicamente es porque la programación es fundamentalmente difícil. Requiere mucho pensamiento lógico y estructurado de una manera que mucha gente simplemente no sabe cómo hacerlo. (O simplemente no puede hacerlo, dependiendo de a quién escuche).

Cosas como LINQ y jQuery hacen que ciertas tareas comunes de manipulación de datos sean mucho más fáciles. Eso es genial para aquellos de nosotros que sabemos lo que estamos haciendo, pero el desafortunado efecto secundario es que baja el listón. Facilita a las personas que no tienen idea de lo que están haciendo comenzar a escribir código y hacer que las cosas funcionen. Y luego, cuando se encuentran con la realidad, y encuentran algo fundamentalmente difícil para el que sus técnicas simples de alto nivel de abstracción no son adecuadas, se pierden, porque no entienden la plataforma sobre la que se basa su biblioteca.

Su pregunta está en el camino correcto, pero al igual que la controversia perenne sobre los videojuegos violentos "convirtiendo a los niños en violentos", tiene la dirección del enlace hacia atrás. Las técnicas de programación fáciles no hacen que los programadores sean estúpidos; simplemente atraen a gente estúpida a la programación. Y realmente no hay mucho que puedas hacer al respecto.

Para mí es el nuevo fenómeno del juguete. Sale algo nuevo (LINQ) y ahora todos los desarrolladores quieren jugar con él.

Ven a LINQ como un martillo y cada problema es un clavo. ¿A quién le importa si es más sencillo hacerlo de otra manera? ¡LINQ debe ser la respuesta! ¡Como cuando todos usaban XML para TODO! ¿Archivo de configuración? XML ¿Almacenamiento de datos? XML Etcétera etcétera

Creo que LINQ ofrece una muy buena oportunidad en C # para resolver problemas utilizando un enfoque más funcional. No deberíamos descartar un nuevo estilo de resolución de problemas solo porque ya tenemos algo que funciona.

Viniendo de un fondo pesado de SQL, me gusta tener la opción de usar la lógica basada en conjuntos en mi C # para describir mejor la intención de mis operaciones.

Dicho eso El contexto es el rey, y cualquier cosa puede ser utilizada en exceso.

LINQ y jQuery son los últimos "juguetes" y a los desarrolladores les encanta mostrar cómo pueden hacer cosas usando lo último.

Si usa Linq correctamente y lo comprende bajo el capó, encontrará todo tipo de nuevas técnicas de programación de vanguardia.

Entonces, si piensas profundamente en las mejoras, sostengo que te convierte en un mejor programador. Si un programador determinado realmente hace esto o no, no es culpa de Linq.

Se puede hacer el mismo argumento para los mapeadores relacionales de objetos. ¿Alguien realmente escribe consultas SQL sin procesar contra tablas de bases de datos? :)

Algunas de esas cosas locas se deben a que las personas están usando el martillo incorrecto, otras son porque están construyendo un súper martillo realmente elegante, pero se han topado con un detalle extraño que debe superarse.

Por ejemplo, si ve una pregunta sobre el uso de linq para generar linq dinámico para usar contra linq no dinámico nueve veces de cada diez, la persona tiene curiosidad de saber si es posible o está ladrando el árbol equivocado, pero hay algunos cosas que puede resolver de esta manera que son difíciles hasta el punto de no ser razonable resolver de otra manera.

Tomo este tipo de preguntas en dos partes:

1. se puede hacer, y si es así, ¿cómo se vería?
2. Si se hace, ¿existe algún riesgo o una alternativa mejor?

He descubierto que casi siempre los hago en ese orden. Responde a la pregunta y también lo ayuda a explicar mejor las posibles alternativas.

No conozco ningún efecto entumecedor en las mentes de los desarrolladores, pero eche un vistazo aquí para ver el efecto de las herramientas / idiomas con mentalidad entumecida en las tasas. ¡Habla sobre bajar la barra!

Estoy de acuerdo con Mason Wheeler. Sin embargo, no es del todo loco tratar de resolver https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq operando en una "secuencia". El problema es que los iteradores de Java y .Net no admiten las 3 operaciones: valor actual, valor siguiente y pasar al siguiente. Clojure puede hacer los 3, y sospecho que en Clojure es más fácil hacerlo bien. Python también tiene co-rutinas, y quiero intentar descifrar eso. http://clojure.org/sequences http://www.try-clojure.org/

De hecho, si la entrada es una secuencia infinita, como http://oeis.org/A007401 , entonces lazy es la única forma.