La herramienta de programación más subestimada [cerrada]

35

Tenemos muchas herramientas excelentes que ayudan mucho a la hora de programar, como buenos programadores, editores de texto, IDEs, depuradores, sistemas de control de versiones, etc. Algunas de las herramientas son herramientas más o menos "imprescindibles" para hacer el trabajo (por ejemplo, compiladores) .

Siempre hay herramientas que ayudan mucho, pero que no reciben tanta atención, por varias razones, por ejemplo, cuando se lanzaron, se adelantaron a su tiempo y ahora están más o menos olvidadas.

¿Qué tipo de herramienta de programación crees que es la más subestimada? Motiva tu respuesta.

tools  developer-tools 
— Anto
fuente
3
¿Nuestros cerebros? - -
— Trufa
¿Quién quiere agregar la entrada Lisp? * sonrisa *
— Mark C

Respuestas:

70

Un pato de goma. Sí, en serio.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Caucho depuración de pato , patito de goma , y la prueba de patito de goma son términos informales utilizados en ingeniería de software para hacer referencia a un método de depuración de código. El nombre es una referencia a una probable historia apócrifa en la que un programador experto no identificado mantendría un pato de goma junto a su escritorio en todo momento, y depuraría su código obligándose a explicarlo, línea por línea, al pato.

Para utilizar este proceso, un programador explica el código a un objeto inanimado, como un pato de goma, con la expectativa de que al alcanzar un fragmento de código incorrecto e intentar explicarlo, el programador notará el error. Al describir lo que se supone que debe hacer el código y observar lo que realmente hace, cualquier incongruencia entre estos dos se hace evidente ...

— Andiaz
fuente
66
Hago esto todo el tiempo con mi esposo. Como técnico de soporte técnico con solo unas pocas habilidades de programación, comprende aproximadamente el 60% de lo que digo, pero me obliga a explicar el 40% que no entiendo también. La cantidad de ocasiones en que funciona es realmente impresionante.
— Ethel Evans
1
Te ries. Tenía un compañero de trabajo que tenía un pato de goma en su escritorio.
— Berin Loritsch
57
Lo intenté, pero mi pato de goma no parecía concentrarse en el problema. ¿Dónde puedo encontrar un pato de goma debidamente calificado con un interés genuino en la programación?
— Steve314
3
Yo uso mi diario para esto. A veces tengo discusiones bastante largas conmigo mismo al respecto. Ojalá pudiera hacerme entender lo que quiero decir, a veces. Escribir esto en un diario a veces ayuda mucho más tarde, cuando me pregunto qué estaba pensando el idiota que escribió el código en el que estoy trabajando.
— Lars Wirzenius
1
@Steve: los investigadores japoneses están trabajando en ello, pero no creo que estén cerca: youtube.com/watch?v=3g-yrjh58ms
— Rei Miyasaka
42

Bolígrafo y cuaderno.

  1. Funciona sin electricidad.
  2. Portátil.
  3. Doodle on / in cuando estás aburrido en las reuniones
  4. Almacenar información útil.
  5. Si está escrito, la gente le da más importancia.
  6. Otros pueden leerlo y aprender.
— Chispeante
fuente
En los viejos tiempos de las grandes corporaciones, los ingenieros y técnicos recibían cuadernos de ingeniería en blanco donde escribían todas esas cosas que tendemos a guardar en varios archivos en nuestros discos duros. Cuando se llenen los cuadernos, se enviarán a un depósito seguro y a prueba de incendios. Si alguien necesitara tener acceso a esas notas, podrían revisar los cuadernos.
— oosterwal
3
Los rusos usaron un lápiz.
— Trabajo
@ Job Jah, ¡todavía uso una botella de tinta! (... Bueno, solo para caligrafía, pero aún así. :))
— Mateen Ulhaq
¿Qué pasa con las Tablet PC?
— Mateen Ulhaq
1
@ Job: ... y vodka!
— Spoike
38

Las herramientas de diferencias parecen estar subutilizadas cuando se comparan salidas de registros o datos en archivos de texto plano. ¿O tal vez eso es solo un nicho? Me parece muy útil y útil para la depuración comparar grandes registros de ejecuciones de programas y señalar uno o dos detalles que cambiaron.

Las herramientas de creación de perfiles de rendimiento también son muy buenas, especialmente cuando golpeas un cuello de botella crítico, pero parece que muy pocas personas están familiarizadas con ellas (y me reconozco hasta cierto punto en esta categoría).

Las buenas herramientas XML son vitales: si está trabajando con archivos XML más de una docena de líneas o esquemas múltiples. A veces necesita algo más que la sintaxis básica que resaltan otros editores. Además, cuando se trabaja con XML, aprender XSL puede ser muy útil. Muchas veces veo lo que podría hacerse en una simple transformación XSL realizada en muchas líneas en el código de la aplicación. Aunque para aclarar: yo no sugiriendo que el propio XML es una "herramienta de programación subestimado"; Sugiero que el valor de los buenos editores XML se subestima, por lo que he visto.

— FrustratedWithFormsDesigner
fuente
1
++ Absolutamente diffse subestima. Sobre el tema de la elaboración de perfiles, no está solo al pensar que deben ser útiles, pero usted mismo no sabe cómo. Mira esto.
— Mike Dunlavey
Sí, he pensado en aprender una herramienta de creación de perfiles, pero nunca llegué a eso
— Anto
23
+1 para perfiles, +1 para herramientas diff, -1 para herramientas XML. Algunas personas, cuando se les presenta un problema, piensan "Lo sé, usaré XML". <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>
— Mason Wheeler
2
@Mason: lindo XML.
— Mike Dunlavey
10
@Mason Wheeler: no sugerí XML como una herramienta para resolver problemas, sugerí Good XML Tools : cuando tenga que trabajar con XML, asegúrese de tener un editor / herramienta que sea muy bueno en eso. Algo que puede ejecutar consultas Xpath, validación de esquemas, transformación, comparación de valor vs. estructura (un tipo especial de herramienta de diferencias, supongo), etc. peor (por cierto me gusta su código XML;)).
— FrustratedWithFormsDesigner
37

Expresiones regulares

Son muy útiles. Ayudan a la hora de buscar a través de archivos de registro, analizar texto, etc. Son extremadamente útiles.

Me resulta extraña la cantidad de personas que conozco que nunca las usan porque hay una pequeña curva de aprendizaje asociada a ellas. Muchas veces veo que la gente hace las cosas de la manera difícil (Nota: antes de la expresión regular, hice las cosas de la manera difícil) cuando una expresión regular simple podía reducirla rápidamente.

— barrem23
fuente
8
Recuerde que las expresiones regulares no son una navaja suiza, incluso si son geniales cuando se aplican correctamente.
— Anto
10
Extremadamente útil, pero a menudo abusado, lo que lleva a un código críptico que no se puede mantener. El viejo dicho "ahora tienes dos problemas" tiene alguna base en la realidad.
— Steve314
44
RegExes es una navaja suiza: una herramienta adecuada para muchos trabajos rápidos, aunque probablemente no sea la herramienta adecuada para construir una casa entera.
— JasonTrue
44
Hmm, por alguna razón siempre tuve la impresión de que la expresión regular estaba lejos de ser subestimada. Demasiado a menudo veo personas buscando una expresión regular donde una simple división / for-loop sería suficiente o cuando las expresiones regulares simplemente no son la respuesta (por ejemplo, analizar xml / html).
— MAK
He visto ambos fenómenos: Regex? Eso es ilegible / lento / inserta peyorativo aquí y "¿Cuál es la mejor manera de analizar (insertar gramática completamente no regular) con una expresión regular?"
— JasonTrue
24

Tus compañeros de equipo. Cuando tengas una idea innovadora y olvides incorporar a tu equipo, nunca escucharás sus preocupaciones o ideas sobre por qué no funcionará o por qué podría ser aún mejor.

Digo esto, porque es fácil pensar que la programación es algo antisocial que la gente hace en las esquinas con sus brillantes ideas. Las personas que piensan que esto subestima el valor de los equipos y sus compañeros de equipo para ayudar a que las ideas / proyectos se hundan / naden.

— Doug T.
fuente
Los buenos compañeros de equipo nunca pueden ser sobrevalorados. La mayoría del software y el hardware pueden.
— Anónimo tipo
19

Google Hay muy pocos problemas que aún no se han resuelto y documentado. Una consulta de Google bien ajustada puede ahorrarles mucho tiempo a todos.

— Adam Crossland
fuente
13
Una buena herramienta, pero no estoy seguro de que lo llamaría subestimado, al menos ya no (tal vez habría estado de acuerdo hace 9 o 10 años).
— FrustratedWithFormsDesigner
12
Lo siento, pero ¿Google lo subestimó? Al menos Google está sobreestimado :)
— eestein
2
¡Sé que sé! Pero mi razonamiento para decir que está subestimado es uno con el que sospecho que estará de acuerdo: al menos el 75% de las preguntas que se hacen en StackOverflow son fácilmente respondibles con Google, ¿sí? Claramente, hasta cierto punto se subestima si tanta gente no lo está usando. Si mi justificación es defectuosa, eliminaré mi respuesta.
— Adam Crossland
3
@ Adam Crossland: el 75% está siendo amable. Creo que es más alto que eso.
— S.Lott
1
@adam @ s.lott, así que supongo que el punto es que Google no se usa correctamente. Con eso estoy de acuerdo. Se podrían responder tantas preguntas (no sería necesario hacerlas) si la gente supiera cómo Google correctamente. Saludos.
— eestein
16

De lejos, la herramienta menos apreciada para encontrar "cuellos de botella" es Ctrl+ Co el botón "Pausa", en un depurador.

Revise el último párrafo de esta publicación , y esta publicación , y esta publicación , para empezar.

Muchas veces veo / escucho que la gente dice "¡El programa es demasiado lento! ¿Qué puedo hacer al respecto? Probé un generador de perfiles (si lo hicieron), pero no entiendo lo que dice. ¿Alguien tiene alguna idea? ¡Ayuda! " Bueno, las conjeturas son solo eso. Lo que siempre he hecho, y otros también, es ponerlo en marcha, interrumpirlo y examinar la pila de llamadas. Si el problema es realmente malo, bingo , está justo frente a ti. Si el problema es solo leve, lo haces varias veces. Todo lo que aparece en más de una muestra, que puede evitar, es un cuello de botella que puede solucionar.

Sí, esto es un cebo a favor, pero funciona.

— Mike Dunlavey
fuente
No se deben subestimar los instrumentos contundentes. Claramente, esta no siempre es la respuesta correcta, pero puede serlo. Llámelo una aproximación de primer orden, para ser refinada por un perfilador real si es necesario.
— Kristof Provost
@ Kristof: Es tentador pensar que sí, y hay problemas que no puede manejar, y hay casos en los que las muestras no son fáciles de obtener, pero los perfiladores tampoco pueden manejar esos casos, excepto por un cierto tipo, como Zoom , e incluso entonces, en realidad no son mejores en el sentido de guiarlo directamente al problema.
— Mike Dunlavey
@Kristof: Este es el tipo de problema en el que la pausa aleatoria no es buena: si tomas una instantánea a tiempo y la estudias, no puedes decir la razón de lo que está haciendo. Ejemplo: procesamiento basado en mensajes, donde no se puede saber de dónde se envió el mensaje o por qué o con qué frecuencia. Otro ejemplo: protocolos asincrónicos, donde se intercambian mensajes, y parece que siempre estamos esperando al otro tipo. Para el procesamiento sincrónico, los perfiladores pueden medir mejor, pero la pausa aleatoria es mejor para encontrar .
— Mike Dunlavey
14

¿Qué tipo de herramienta de programación crees que es la más subestimada? Motiva tu respuesta.

El compilador.

La mayoría de las personas no se toman el tiempo para comprender lo que hace su compilador elegido. Simplemente sienten que convierte el código en un programa ejecutable y eso es todo lo que pueden llegar. En la mayoría de los modernos, hay varias configuraciones que puede alimentar para que haga lo que necesita. Aquí hay un ejemplo, apuesto a que la mitad de los desarrolladores en su oficina no tienen idea de cómo configurar la advertencia como nivel de errores (suponiendo que realmente tenga uno). ¿Qué opciones tiene para generar símbolos de depuración? ¿Qué optimizaciones (o qué nivel de) desea que haga? La lista continua.

— Kevin
fuente
3
@Kevin: y agregaría formas de escribir código para que el compilador realice verificaciones por usted (para los idiomas estáticamente escritos). La mayoría de los desarrolladores usan tipos listos para usar (como cadenas) para representar cualquier tipo de información, donde podrían definir tipos simples pero incompatibles para datos no relacionados ... y tienen el compilador que no estropearon al pasar argumentos.
— Matthieu M.
@Matthieu M Ese también es un buen punto. Muchas personas olvidan las formas fáciles en que puede ayudarlo.
— kemiller2002
3
Cada advertencia del compilador es un regalo precioso. ¡No los ignores! ¡Pregunta por más! -El error debe ser obligatorio.
— Kristof Provost
@Kristof: -pedantic -Wall -Wextra -Werror... aunque puede ser difícil construir algo entonces: p
— Matthieu M.
Tal vez sea sólo yo, pero si "la mitad de los desarrolladores" no sé qué pasa con símbolos de depuración" no es una exageración, es bastante desalentador.
— kizzx2
10

Tu cerebro. Otras herramientas no tendrían mucho significado sin él.

— jnevelson
fuente
44
He hecho que el mío sea mayormente inutilizable en ocasiones.
— David Thornley
3
"más o menos olvidado": -S
55
Yo diría que está subestimado. Demasiadas personas siempre están buscando atajos para no tener que pensar. No hay reemplazo para el sentido común y la lógica, y las herramientas simplemente no pueden reemplazar eso.
— jnevelson
2
Estoy de acuerdo con Jonathan, el cerebro a menudo se subestima. De hecho, muchos programadores confían en los pocos trucos que conocen en lugar de salir de la caja y ocasionalmente escribir un caso de prueba a medida (barato y sucio, desechable) y una herramienta de prueba para investigar el problema en cuestión. En muchas ocasiones les he dado a los desarrolladores los medios para ir más allá de su estado de pensamiento y resolver sus problemas con no más que unas pocas preguntas.
— asoundmove
1
Algunos comentarios me hicieron cambiar de opinión, +1 :)
— Anto
10

Buen viejo:

print

A veces es útil un depurador o perfilador o un diagrama de flujo UML. Y a veces te vuelven loco. Siempre me encuentro recurriendo al uso de declaraciones de impresión (o trace o NSLog o what-have-you) solo para asegurarme de que mi código está haciendo lo que creo que está haciendo cuando creo que lo está haciendo.

— JRW
fuente
Creo que esto depende del idioma y el depurador. Los tipos de depuradores que ofrecen la mayoría de los IDE decentes hoy en día para los idiomas populares le permiten hacer las cosas mucho más fácilmente que las declaraciones impresas.
— Billy ONeal
8

Scripts viejos y sencillos ... no importa cuántos lenguajes de la próxima generación que desarrollemos, seguimos dependiendo en gran medida de los scripts, también la mayoría de las tareas diarias se pueden lograr escribiendo algunas líneas de scripts.

— Gaurav Sehgal
fuente
1
Mira ... No estaría de acuerdo con este. Sí, los scripts pueden automatizar algunas tareas. Pero a menudo se llevan mucho más allá del sentido hasta el punto de convertirse en una gran pica de espagueti.
— Billy ONeal
1
Es cierto que los scripts grandes son horribles de ver y uno podría usar perl o python para ello. Aunque todavía son excelentes para hacer pequeños trabajos.
— Gaurav Sehgal
@ Billy Usa Python. Problema de spaghetti resuelto :)
— Evan Plaice
5

Perl y otros lenguajes de script. Ideal para tareas que son demasiado complicadas para herramientas GUI como Agent Ransack.

— Kevin Cline
fuente
1
No estoy seguro de que estén subestimados ...
— Anto
3
Definitivamente subestimado ... especialmente Perl. Es un lang. muy bien diseñado con el lema de mantener las cosas simples ... como tal, no tiene precio para tareas rápidas que solo deben realizarse.
— Rook
@Rook: No estoy seguro de cómo un lenguaje con más de 100 operadores puede considerarse "simple". Útil, posiblemente. Pero no es "simple".
— Billy ONeal
@Billy - Simple no excluye poderoso. Encuentro calculadoras simples. No sé qué hace la mitad de las 300 funciones en la mía, pero eso no reduce su simplicidad.
— Torre
4

Métodos abreviados de teclado que permiten una refactorización rápida, frecuente y segura. Aprender a extraer (o en línea, etc.) variables, métodos, constantes o clases al presionar algunas teclas cambió radicalmente la forma en que codifico. Solo refactorizará con frecuencia (es decir, suficiente) cuando el costo sea mínimo, por lo que, en lo que a mí respecta, es esencial hacer que estos atajos sean una segunda naturaleza.

Por lo tanto, generalmente, use buenas herramientas (IDE / editor) y aprenda a aprovechar al máximo las funciones que ofrecen.

Las pruebas unitarias y TDD vienen después, para mantener su código comprobable y evitar el miedo a la refactorización.

Úselos y avanzará fácilmente hacia la escritura de un código mantenible correcto que se ajuste al principio DRY y se auto documente.

— Alba
fuente
4

Las pruebas unitarias ofrecen los siguientes beneficios:

  • Los desarrolladores se convierten en los primeros clientes del código. Cuanto más rápido se detecta un error, menos costoso es repararlo. Los errores pueden detectarse antes de una compilación, instalación o implementación .
  • Las pruebas cambian su perspectiva sobre el código. ¿Está claro el diseño? ¿Maneja casos de esquina?
  • El efecto Hawthorne mejorará la calidad, simplemente al anunciar que un equipo publica métricas de calidad / prueba.
  • Incluso si las pruebas no se controlan en el control de fuente, pueden ser una excelente manera de explorar y aprender un nuevo terreno.
  • ¡Una alta probabilidad de menos errores!
— Michael Easter
fuente
4

Generadores de código

Los generadores de código pueden crear una gran cantidad de código eficiente y sin errores desde una definición simple. Los usos de tipo ORM son los más obvios para crear clases de acceso a datos, pero hay muchos más usos potenciales.

El soporte de generación de código parece estar todavía en pañales tanto desde el punto de vista del programador como del marco, pero creo que es algo que veremos más y más. En .NET puede comenzar a incursionar con las cosas de CodeDOM .

— konrad
fuente
Me gusta escribir generadores de código, no es lo más fácil de hacer, pero es muy útil.
— Zachary K
3

Yo uso AgentRansack en gran medida. Es una gran ayuda buscar miles de archivos muy rápidamente. Me ha ahorrado mucho tiempo, pero no conozco a muchos programadores que lo conozcan o lo usen.

— JakeRadakovich
fuente
3

Métodos formales

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

Es difícil exagerar su importancia. Cada ciclo y cada declaración if comienza como una idea que requiere algún tipo de "prueba". La mayoría de los programadores hacen esta prueba la mayor parte del tiempo en sus cabezas. Usted pregunta qué hace la declaración if y pueden articular, de manera sólida y lógica, cuáles son las opciones y por qué las opciones son completas, consistentes y exclusivas.

Pero algunos parecen adivinar al azar. Necesitan más ayuda y los métodos formales podrían ser el tipo de ayuda que necesitan.

Es solo álgebra (y cálculo) para el código. Nada demasiado complejo o sofisticado.

— S.Lott
fuente
Los he encontrado con frecuencia útiles para hacer las cosas simples correctamente para poder confiar en ellas mientras depuro las cosas más complicadas. Mi experiencia es que los métodos formales eliminan bastante bien los errores sutiles, dejando solo los evidentes obvios que se detectan fácilmente con las pruebas.
— David Thornley
3

Los patrones de diseño físico, como salir de la silla para correr rápidamente a la luz del sol y el aire fresco, mantienen nuestros cerebros funcionando al máximo.

— Joe Chrysler
fuente
3

Bueno, es Half Life 2 (inserta tu juego favorito aquí). Si tengo un problema que no puedo resolver, simplemente renuncio y empiezo a jugar con mi juego favorito y, de repente, la solución aparece en mi mente. Entonces, para ser honesto, no es un juego o algo así, sino hacer otra cosa . A menudo veo personas sentadas en un problema durante horas sin resolverlo y todo lo que deben hacer es desconectar su cerebro por un corto período de tiempo.

— Adam Arold
fuente
3

Desbordamiento de pila : ayuda rápida de expertos cuando está atascado

Sitio de preguntas y respuestas para programadores profesionales y entusiastas. Está construido y administrado por usted como parte de la red Stack Exchange de sitios de preguntas y respuestas. Con su ayuda, estamos trabajando juntos para crear una biblioteca de respuestas detalladas a cada pregunta sobre programación ...

— mosquito
fuente
+1, pero ya no se subestima realmente
— MAK
44
tal vez incluso sobreestimado, o al menos sobreutilizado
— Anto
3

Creo que es Notepad / TextPad / simples programas de edición de texto. Todos tienen un momento en el que necesitan una solución rápida que no requiere abrir un IDE y solo necesitan una edición rápida. Y todas las computadoras tienen algún tipo de programa de edición de texto simple.

— Peter Mortensen
fuente
2

Afirma y una buena alwaysAssert()función. En mi humilde opinión, estos son más importantes que las pruebas unitarias, porque las pruebas unitarias solo pueden encontrar errores en los casos específicos que pensaste probar. Si el mismo programador escribe el código y las pruebas, probablemente perderá los mismos casos extremos en ambos. Además, a veces las pruebas unitarias no son prácticas porque el entorno en el que funciona el componente y / o los datos en los que opera es demasiado complicado para encontrar un caso de prueba artificial.

La belleza de las afirmaciones radica en su capacidad para documentar supuestos y probarlos en entradas no inventadas . Si alguno de estos supuestos es incorrecto, su código falla en lugar de "funcionar" pero produce resultados sutilmente incorrectos. También falla más cerca de la raíz del problema que sin las afirmaciones. En la práctica, si declara explícitamente suficientes suposiciones sobre un fragmento de código y todas estas suposiciones son correctas, entonces el código generalmente es correcto.

Una queja común acerca de las afirmaciones es que se pueden desactivar. En mi humilde opinión, cada idioma o biblioteca estándar debe tener una alwaysAssert()función o equivalente aproximado que haga lo mismo assertpero que no se pueda desactivar. Esto se puede utilizar para verificar supuestos en áreas de código que no son críticas para el rendimiento, donde los beneficios de desactivar las afirmaciones son insignificantes.

— revs dsimcha
fuente
Convenido. Pero desafortunadamente, herramientas simples pero eficientes como esta a menudo se subestiman.
— Peter Mortensen
2

La tecla F1. - Útil para programas que no conoces y para programas en los que estás trabajando. (Suponiendo que es una aplicación grande).

Potentes para filtrar los problemas cuando los usuarios informan de errores en función de su interpretación de cómo debería funcionar el software. Por supuesto, podría ser que el diseño en sí fuera defectuoso. Pero esa es otra historia.

— Jeremy Edwards
fuente
2
Ambos subestimados y también subestimados.
— Tipo anónimo
Muy subestimado por los desarrolladores de la aplicación que está utilizando en este momento; como tal, la ayuda contiene poca o ninguna información útil.
— Poke
2

Varias utilidades de núcleo UNIX, pero principalmente findy de vez en cuando grepo ed. La capacidad de encontrar cosas en nidos profundos de archivos es invaluable, particularmente cuando de repente heredas una base de código y tienes que arreglarla. Incluso si dicho código está bien documentado, probablemente tendrá que cazar, y una gran comprensión de findesto lo mata.

— kojiro
fuente
2

Curiosidad

Llámalo el "Enigma de la programación". ¿Qué es una herramienta en comparación con la persona que la maneja? El deseo de saber cómo y por qué algo funciona o no funciona expande el conocimiento de uno más que cualquier herramienta específica y eso es cierto más allá de la programación.

— Thomas
fuente
1

Cola

Tail se puede usar para monitorear el archivo de salida del registro del programa en tiempo real. Ha sido de gran ayuda al desarrollar sistemas que no proporcionan a otros medios para leer el registro.

Los programas de ejemplo son;

— Declaración
fuente
Mac OS X es un sistema UNIX. No es necesario mencionarlo por separado.
— derecha el
0

Reuní un generador de gráficos de llamadas de Perl una vez. Fue extremadamente útil, pero cayó demasiado en código no procesal o rutinas fuera de archivo.

— Paul Nathan
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.