language agnostic - pli - ¿Alguna vez se ha limitado a usar un subconjunto de características del lenguaje?
pl 1 (19)
Aunque PHP originalmente era un lenguaje de plantilla, se ha convertido en un lenguaje de programación OO completo. Por esta razón, algunos dicen que ya no es adecuado usar como lenguaje de plantilla.
Realmente, sin embargo, es solo una cuestión de disciplina. Al crear plantillas HTML / PHP, me limito al subconjunto más simple posible: condiciones y bucles y sin lógica comercial alguna. No hay instancia de objeto. Sin definiciones de funciones. La lógica más compleja se separa en otros archivos.
¿Alguna vez se ha limitado a usar un subconjunto de características del lenguaje y, lo que es más importante, por qué?
Tengo curiosidad por descubrir quién elige usar solo ciertas características del lenguaje y evitar otras para ganar a lo grande en áreas tales como, entre otras, el uso de la memoria, la velocidad de ejecución o la facilidad de lectura y mantenimiento. Y al hacerlo, produjo los resultados esperados o tal vez solo obstaculizó algún otro aspecto de la producción de software. ¿Hay alguna historia de advertencia o historias de éxito que valga la pena compartir con respecto a este tema?
Ciertamente lo haces cuando codifica código c / c ++ para que funcione tanto en Linux como en Windows, por lo que te limitas a ANSI c / c ++, así que creo que el soporte multiplataforma es una de las razones.
otras razones: si desea la máxima compatibilidad con software / OS de gran difusión (como WinXP, IE 6.0), entonces apunte su software a esas aplicaciones / os (como dot net framework 2.0 y no 3.5 y Ie 6 y no ie.8) - para tener una mejor compatibilidad con los usos anteriores.
lo mismo ocurre con la compatibilidad de hardware anterior / compatibilidad con dispositivos gráficos antiguos ect ...
En .NET, tenemos una aplicación que DEBE ejecutarse en Windows 98, por lo que estamos limitados al framework 2.0, ya que las versiones más nuevas no se ejecutan en este sistema operativo ... Eso es triste. No puedo usar LINQ, métodos de extensiones y esas cosas.
En muchos casos, lo hace inconscientemente, utiliza el subconjunto que conoce y deja de lado las características desconocidas. En otros casos, hay más de una forma de hacerlo, y usted elige atenerse a una forma todo el tiempo, porque hace que un programa sea más fácil de leer cuando usa menos funciones de idioma. (Especialmente cuando "al revés" no tiene una ventaja particular, por ejemplo, está aquí para agradar a las personas que provienen de un idioma diferente)
La mayoría de las personas programa subconcientemente en un subconjunto informal del idioma de su elección con el que se sienten cómodos. Por ejemplo, mi primera reacción al presentar un vector C ++ que necesita iteración es alcanzar un bucle for, en lugar de escribir un predicado y usar un algoritmo de biblioteca estándar. Posiblemente un error de mi parte, pero al menos sé que el algoritmo está ahí si realmente lo necesito.
La última vez que recuerdo haber escrito con consciencia en un idioma de subconjunto fue en los años 80 cuando la mayoría de mis plataformas de destino admitían FORTRAN 77, pero una no funcionaba correctamente, así que tuve que escribir en un FORTRAN 77 / FORTRAN IV híbrido. Fue un dolor: las cosas han mejorado mucho en los últimos años, gracias principalmente al movimiento FOSS.
Muchas veces. La razón principal para mí es la compatibilidad multiplataforma. Ejemplos:
1) (hace años) las plantillas fueron eliminadas del estándar de codificación de mi empresa, ya que eran demasiado no estándar en toda la gama de compiladores que teníamos que admitir
2) uso de excepciones / rtti para c ++ - un no-no si está apuntando a una plataforma incrustada así como de escritorio (descargo de responsabilidad - no he hecho nada de esto en años, entonces quizás sea más aceptable ahora aunque lo dudo )
3) Remoting de .NET si está escribiendo una aplicación para escritorio .NET y para WinCE - mayor dolor de cabeza en este momento :-(
Obviamente, si las funciones están en desuso, es una buena idea evitarlas, incluso si están técnicamente disponibles.
Pero también, si vas a distribuir scripts interpretados para ejecutar en una combinación de máquinas, a menudo evitaré las funciones nuevas, así que no obligo a las personas a actualizar PHP / Perl / lo que sea para poder ejecutarlo .
Sí.
C ++ es un lenguaje tan grande y complejo que es difícil contratar un equipo que pueda usar todas las funciones en toda su complejidad. Escribo pautas de estilo que indican a los ingenieros que utilicen ciertas características y eviten otras. Es angustioso tener ingenieros atascados en un error, y que te digan que nunca supieron lo que significaba cierto constructo. ¿Mal ingeniero? Tal vez, pero tenemos que trabajar en la realidad.
Como han mencionado las personas, los idiomas como Javascript tienen algunas características que pueden ocasionarle problemas, por lo que es mejor evitarlos.
Ambos, y otros lenguajes maduros como PHP y Ruby, tienen características de muchos paradigmas diferentes. Para usarlos de manera efectiva, no necesariamente evita ciertas características, sino que llega a un acuerdo sobre cómo va a utilizar el vasto conjunto de herramientas que tiene disponibles.
Me siento un poco diferente sobre Java. Es un lenguaje mucho más simple y creo que es realista esperar que los ingenieros conozcan todo el lenguaje. A veces se evitan ciertas características para compatibilidad con versiones anteriores, pero de lo contrario, quiero que los ingenieros conozcan y utilicen todo Java.
Si todo el tiempo.
Porque uso Perl, y la mayoría de la gente está de acuerdo en que muchas de las características de nuestros idiomas no se utilizan a menos que realmente lo necesite y sepa lo que está haciendo. Por ejemplo, las referencias simbólicas son compatibles, pero no debe usarlas. goto existe, pero no deberías usarlo. Puede reutilizar etiquetas de variables como tipos diferentes, por ejemplo, $var , @var %var , %var , pero tampoco debe hacer eso. No se puede use strict para que las variables no declaradas se conviertan automáticamente en entradas de tabla de símbolos, pero realmente no se debe hacer eso.
La razón principal es que muchas de estas características tienen consecuencias tanto obvias como esotéricas que pueden introducir errores sutiles y difíciles de depurar en su programa si se usan de forma descuidada. Perl hace posible muchas cosas y puede resultar atractivo utilizar ciertas características de lenguaje inusuales para ahorrar unos minutos de codificación. Por supuesto, hay momentos en los que las funciones esotéricas son útiles, y es genial que estén ahí para que aproveches en Perl, en lugar de estar completamente ausente. Pero se necesita experiencia para saber cuándo vale la pena ese ahorro, porque la gran mayoría de las veces usted solo está creando una pesadilla de mantenimiento para usted y para otros en el futuro.
Me gusta decir TMTOWTDI, BMOTWAW; Hay más de una forma de hacerlo, pero la mayoría de esas formas son incorrectas.
Es perfectamente posible crear aplicaciones Perl grandes, alfabetizadas y mantenibles. Y una buena parte de hacerlo es restringirse a un subconjunto de características del lenguaje.
Tiene sentido no usar funciones que sus codesarrolladores no entienden. En c ++, eso se aplica a la mayor parte del lenguaje :), pero c # también tiene construcciones interesantes. Los idiomas antiguos como Delphi aún pueden contener goto. Tiendo a evitar todas las plantillas y XML, ya que los he encontrado imposibles de SECAR
Un caso es cuando estás escribiendo un compilador de un nuevo idioma en sí mismo. Usted puede:
- Use otro idioma para escribir un compilador simple para un subconjunto del nuevo idioma.
- Use ese subconjunto del nuevo idioma para escribir el compilador para la versión completa de sí mismo.
GOTO que en algunos círculos se considera perjudicial.
No usé algunas características .NET en un proyecto de portal que tendrían problemas cuando se ejecuta en entornos parcialmente confiables porque teníamos que asegurarnos de que los clientes pudieran implementar la solución en servidores con ensamblados con políticas de confianza débiles.
¡Lo que más duele es que no se puede usar ningún reflejo!
Lotus IBM introdujo el método getAllEntriesByKey de la clase NotesView en LotusScript R5, realmente no comencé a utilizarlo por desconocimiento hasta hace un par de años, ahora es una parte básica de mi programación como alternativa a getAllDocumentsByKey.
No hay nada de malo en getAllDocumentsByKey y lo uso todo el tiempo, pero si la vista que mira tiene cientos o incluso miles de registros (documentos para un desarrollador de Notes), entonces el escaneo de la colección que recibe puede ser muy lento. Sin embargo, si el valor del documento es una entrada de la columna de visualización y luego escanear el viewEntryCollection que obtiene de getAllEntriuesByKey es mucho más rápido, no hace que el código anterior sea incorrecto o incluso inutilizable, solo necesita saber cuándo usar cada uno.
La semana pasada grabé un proceso que tuvo que iterar a través de una colección que resultó podría contener entre 0 y 22,000 entradas, para 200 registros tardó 60 segundos en ejecutarse. El nuevo código finalizó en 2 segundos (agregué el código temporal de tiempo) y, lo que es más importante, requirió la misma cantidad de tiempo para 500 documentos, es una gran victoria para diez minutos de trabajo, incluidas las pruebas unitarias. El método estaba disponible para los desarrolladores años atrás cuando escribieron el subtítulo, pero o no lo sabían o más bien no tenían confianza / no entendían las implicaciones de rendimiento.
Solo podemos usar lo que conocemos y en lo que tenemos confianza. Mientras más trabajo de desarrollo haga, más probable es que aumente su experiencia y pueda utilizar más funciones de un idioma para entregar software de calidad a sus clientes.
Planeo estar en las próximas semanas mientras llevo a Lua al DLR.
En Verilog y VHDL (lenguajes de programación utilizados para diseñar chips), siempre tenemos que usar los subconjuntos que son "sintetizables" cuando se diseña el chip. El idioma completo se puede usar para bancos de pruebas (pruebas unitarias).
Utilizamos XSLT en gran medida para muchos de nuestros componentes. La mayoría de los componentes son antiguos) usa analizadores antiguos, que no son compatibles con XSLT 2.0, por lo que todavía estamos usando funciones XSLT 1.0 aunque XSLT 2.0 ofrece muchas funciones buenas.
Aunque no es estrictamente una "función de idioma", una construcción que evito en C # es lock(this)
Es una de las causas principales de las condiciones de interbloqueo en el código de subprocesos múltiples, ya que cualquiera puede bloquear la misma referencia.
El libro de Douglas Crockford, Javascript: The Good Parts es un excelente ejemplo de esto. Enumera las "características" en javascript que deben evitarse y proporciona alternativas que usan las "partes buenas" del lenguaje.
Algunas de las partes malas son:
eval
más lento, más difícil de leer, peligrosamente inseguro==
confuso y ambiguo con operandos de tipos diferentescon
resultados impredecibles