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

36

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?

programming-practices .net

— Aaronaught
fuente

66

+1 para "asumió que la solución ideal involucraría a Linq sin pensarlo realmente". Está realmente más allá de mí.

— Jaco Pretorius

1

LINQ es lento ...

2

@Pierre: ¿Sobre qué base haces esa afirmación?

— Aaronaught

55

@Mason: Ese es un punto de referencia absolutamente horrible escrito por alguien que claramente no sabe lo que está haciendo. ¿Benchmarking en garrapatas? Notación húngara? Y la versión de Linq ni siquiera hace lo mismo, trata de repetir cada resultado en lugar de detenerse en el primero. Sin mencionar que toda la premisa es tonta, como se discutió de manera concluyente en la pregunta candente de hoy .

— Aaronaught

3

Y, por cierto, @Mason, Linq tiene muchas optimizaciones integradas. Para casi cualquier método que pueda optimizarse, primero busca una interfaz que admita el método optimizado. Para otros métodos basados en conjuntos como equijoins, crea tablas hash. No optimiza su código para usted, pero tampoco lo hará más lento; La mayoría de las ralentizaciones documentadas reales en el mundo real se deben a lambdas / cierres que son independientes de Linq.

— Aaronaught

52

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.

— Mason Wheeler
fuente

30

+1 para "Las técnicas de programación fáciles no hacen que los programadores sean estúpidos; simplemente atraen a personas estúpidas a la programación".

— Steven Evers

1

Una gran cosa acerca de LINQ es que me permite crear una solución prototipo en un enfoque funcional. Luego, una vez que tengo una solución libre de errores, puedo usarla como banco de pruebas para una versión imperativa optimizada. Si la tarea es lo suficientemente simple como aplicar un solo filtro, ni siquiera me molestaré.

— ChaosPandion

55

Todavía dudo que LINQ atraiga a programadores incompetentes, por lo que he visto, parece ser uno de los conceptos más difíciles de entender para los novatos, pero esta parece ser la mejor respuesta hasta ahora.

— Aaronaught

1

Deberías poner un copyright en esa última oración. Bien dicho, señor.

— AJ Johnson

1

Gracioso. Para mí, LINQ no es un concepto particularmente fácil de dominar. Si está haciendo algo importante, muy pronto debe dejar de pensar en el volante y comenzar a comprender la transmisión. Te estoy mirando lamdas!

— Brian MacKay

13

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

— PSU_Kardi
fuente

55

No quiero comenzar un debate XML aquí, pero vale la pena señalar que XML es realmente bueno en ambas cosas. No siempre es óptimo : si los archivos de configuración no necesitan estructurarse, los KVP son mejores, y si la compatibilidad entre aplicaciones no es un requisito, entonces un formato binario es claramente mejor para el almacenamiento / serialización. Pero no creo que XML sea un gran ejemplo porque tendió a ser utilizado en áreas donde era simplemente subóptimo en lugar de totalmente inapropiado.

— Aaronaught

44

+1: Vale la pena estirar las herramientas para ver cuántos problemas se pueden transformar en una uña cuando aprendes una tecnología.

— Steven Evers

+1: Otros ejemplos de este tipo de martillo mágico son jQuery (como se menciona en la pregunta) y expresiones regulares. No es que estas cosas sean malas, de hecho son realmente útiles, pero no son la respuesta a todo.

— Tim Goodman el

14

Creo que la analogía "LINQ es un martillo y cada problema es un clavo" lo está llevando demasiado lejos. Yo diría que LINQ es un martillo tan bueno que cuando una gran parte de su trabajo involucra clavos, puede meterse en una ranura y no notar que acaba de clavar un tornillo. Incluso si no eres un mal programador.

— Carson63000

@Aaronaught: Por otro lado, el uso de XML con nombres de campo largos me pareció subóptimo para la transmisión de datos a través de enlaces de radio de bajo ancho de banda y no completamente confiables. Por otra parte, eso es también lo que pensé del diseño de la base de datos en ese producto.

— David Thornley

10

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.

— dotjosh
fuente

¿Quién está despidiendo? Uso Linq todo el tiempo, solo me preocupa la cantidad de incidencias que veo de las personas que lo usan (o intentan usarlo) para problemas que son claramente iterativos y no basados en conjuntos.

— Aaronaught

Estoy muy acostumbrado a tratar de resolver los problemas que se requieren para ser escritos en SQL, y usar la lógica basada en conjuntos en lugar de cursores para hacerlo. El abuso de herramientas siempre sucederá, pero supongo que al menos si escriben código LINQ deficiente en lugar de código de procedimiento deficiente, una versión posterior de .NET al menos podrá paralelizarlo más fácilmente.

— dotjosh

2

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

— Dan Diplo
fuente

Concuerdo con esta declaración. No estoy tan seguro si explica este fenómeno en particular. Las personas que hacen estas preguntas realmente no parecen ser del tipo presumido, aunque ayudaría a explicar por qué otros programadores intentan responder las preguntas como se les pregunta en lugar de abogar por un enfoque más sensato.

— Aaronaught

@Aaronaught - Sí, supongo que estaba pensando más en por qué la gente responde con las preguntas utilizando este enfoque.

— Dan Diplo

2

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? :)

— Robert Harvey
fuente

10

Hey, escribo SQL crudo ... olfateo

— Aaronaught

2

Raw SQL es la mejor apuesta si sabes lo que estás haciendo.

— Fosco

1

+1 para el argumento "te hace un mejor programador". Comprender linq y especialmente los métodos que lo soportan definitivamente ha mejorado mi comprensión de algunos conceptos de programación muy útiles.

— John M Gant

1

Creo que alguien se ofendió por el comentario de ORM vs. SQL sin formato. No fui yo; Utilizo ambos, y entendí que el comentario era irónico.

— Aaronaught

1

Nunca confiaría en mis consultas de bases de datos complejas a la basura que escribe un ORM. Está bien para cosas simples, pero ugh para informar consultas de tipo. Una vez más, en manos de alguien que sabe lo que está haciendo, ORM es algo bueno, en manos de alguien que es demasiado vago para comprender las bases de datos, un desastre por delante.

— HLGEM

1

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:

se puede hacer, y si es así, ¿cómo se vería?
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.

— Cuenta
fuente

0

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!

— Pete Wilson
fuente

0

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.

— Trabajo
fuente

"Linq" no significa necesariamente "iteradores" ni "perezosos"; de hecho, la mayoría de Linq se trata realmente de árboles de expresión. Podría fácilmente, si lo desea, implementar su propio agregado de 3 valores o N con un cierre y muy poco código en C #. El problema surge cuando las personas no tienen idea de cómo hacer eso, o incluso cómo comenzar, y solo buscan un encantamiento mágico que vive en el System.Linqespacio de nombres.

— Aaronaught

@Aaronaught ... '' '"Linq" no significa "iteradores" ni "perezosos" necesariamente' '', bueno, Linq puede parecerse a SQL pero este azúcar sintáctico se compila en un código IL real, que, si se descompila , se vería equivalente a un grupo de IEnumerable [<T>] s conectados juntos. Eso es perezoso y usa enumeradores, que en otros idiomas se llamarían iteradores. Pero sí, el problema es que LINQ hace que la codificación parezca fácil, y los no calificados lo intentan. Algunos todavía podrían convertirse en programadores decentes tal vez. Si C # es su primer idioma y son novatos totales, entonces se trata de un lenguaje extenso.

— Trabajo

Claro, Linq to Objects (no Linq to SQL, Linq to Entities, Linq to DataSet o cualquier otra rama de Linq) se basa en iteradores y ejecución diferida, pero todo eso está oculto. Los bloques iteradores y la yielddeclaración existían antes que Linq, al igual que los delegados. Los cierres llegaron en el mismo lanzamiento que Linq, pero pocas operaciones "Linq" puras realmente requieren captura de variables locales. Preguntando "¿Cómo puedo hacer [descripción de operación / función completamente iterativa] con Linq?" revela una profunda ignorancia tanto de Linq (lo que se supone que debe hacer) como del lenguaje en sí.

— Aaronaught