Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Temas relacionados > Debates
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

 
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 28-02-2019
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Aforismos sobre diseño de lenguajes de programación

Ya que estoy investigando mucho sobre diseño de lenguajes de programación, me encontré con esta lista que seguramente da buenos puntos a considerar:

http://www.rntz.net/post/2017-01-27-...pl-design.html
  1. It is easier to say what not to do, than to do what is needed. So do not be discouraged by this list; you, too, have something to contribute.
  2. Every decision that matters is a tradeoff. There never was, and never will be, a perfect language. As humans have many purposes, so must programming languages.
  3. The measure of a language is not what is possible in it, but what it makes easy.
  4. Thus, a language's strongest characteristic is what it makes automatic: What don't you have to think about when using this language?
  5. There is power in restraint. The less a language does, the more can be done to it.
  6. Types are a tool of thought. They exist in the mind first, and in the machine second.

    A statically typed language, therefore, guides your thinking. This is useful.
    A dynamically typed language lets you think freely. This too is useful.
  7. Shorten the edit-compile-run cycle. Then shorten it some more.
  8. Readability beats writeability. Or, predictability beats convenience.

    It is better that code be transparent to read than convenient to write. This is less important for one-shot scripts, and more important for large codebases tended by many people.
  9. Brevity is good, until it's bad.

    Brevity both helps and harms readability. You can only fit so much in your head at one time. Terse notation helps more fit in; it aids in reading and recognizing patterns. But it also steepens the learning curve and increases memory load.
  10. Notations must be justified by frequency of use and power of thought gained.
  11. A programming language is low level when its programs require attention to the irrelevant.
    — Alan Perlis

    This is, of course, a relative condition: Irrelevant to what? Irrelevant to whom? We often think of languages as being lower- or higher-level than other languages. Actually, they're below or above certain concerns.
  12. Explicitness is good, until it's bad.

    Explicitness is good when it prioritizes readability over writeability.
    Explicitness is bad when it requires attention to the irrelevant.

    Can't it do both? Of course it can!
  13. Not everything is an object. Nor is everything a function, a string, a process, an actor, a value, a thunk, a message, a list, a file, or an expression. Not everything is data, nor is everything code. Not everything is lazy, immutable, pure, copyable, serializable, sortable, or transmissible over the network. goto is not the only control operator, and neither is call/cc.
  14. And yet, only by taking things to extremes do we truly learn their limits.
  15. Always bet on text.
  16. Yet long shots are worth taking.
  17. The medium matters. Consider how the programmer will interact with your language or system. Will they use text files? a REPL? a shell? an IDE? a GUI? a spreadsheet? a structure editor? a browser? The language design should harmonize with the available methods of interaction. Indentation-sensitivity is a terrible fit for a line-oriented interactive shell, for example.
  18. Syntax matters less than you think.
  19. Syntax matters more than you think.
  20. Syntax is a pain in the ass.
  21. Performance is a lot like syntax.
  22. "Declarative" means you can use it without knowing what it's doing.

    All too often, it means you can't tell what it's doing, either.
  23. What applies to languages, applies to libraries. Consider, for example, how predictability beats convenience might apply to the design of a numerical library.
  24. Performance matters. Syntax matters. Documentation matters. Libraries matter. Culture matters. First-mover advantage matters. Compatibility matters. Corporate support matters. Error messages matter.

    But in the end, only two things are sure when it comes to language popularity:
  25. Languages teach ways of approaching problems. Once you know the way, you don't always need the language.

    ... but your friend might!
  26. Before learning $LANG: read code, squash bugs.
    After learning $LANG: read code, squash bugs.
__________________
El malabarista.
Responder Con Cita
 


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Lenguajes de Programación Utilizados en el 2013 nlsgarcia La Taberna 4 06-01-2014 16:27:14
Comparativas del rendimiento de lenguajes de programación movorack Noticias 10 04-05-2011 19:17:49
Ranking de lenguajes de programacion mario2000 Varios 13 25-03-2008 10:16:37
Convertidores Lenguajes de programacion JXJ Varios 4 08-12-2007 08:02:41
Lenguajes de programación Isaac Debates 16 27-02-2004 06:28:21


La franja horaria es GMT +2. Ahora son las 15:04:42.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi