Doble licencia con la Licencia Pública General GNU
Acepto licenciar adicionalmente cualquiera de mis contribuciones (de las cuales poseo los derechos de autor) bajo la Licencia Pública General GNU (GPL) versión 2. Tenga en cuenta que otros colaboradores podrían no hacer lo mismo, por lo que si desea utilizar mis contribuciones bajo los términos de la GPL, consulte las guías de licencias múltiples .
Wikidatos
Conflictos entre idiomas: https://www.wikidata.org/wiki/User:Diego_Moya/Wikidata:Interwiki_conflicts, https://www.wikidata.org/wiki/User:Diego_Moya/Help:Merge
wp:Utilice la Wiki -contra el uso de muros rojos para contenido eliminado-. (aún por escribir)
WP:Tres niveles de atribución (verificabilidad, importancia y notabilidad) son utilizados por diferentes políticas para determinar qué contenido conservar y qué eliminar.
verificabilidad: el contenido puede incluirse en un artículo relacionado, siempre que no tenga un peso indebido.
Significado: forma débil de "enciclopédico", suficiente para proporcionar "contexto" desde un punto de vista.
en profundidad pero no neutral (no independiente ni múltiple)
notable: forma fuerte de "enciclopédico", suficiente para definir temas válidos.
Wikipedia está terminada. La mayoría de la comunidad activa ya no considera aceptables los procesos que permitieron que el proyecto creciera. Por lo tanto, aunque el producto aún puede recibir pequeños retoques y mejoras, el trabajo principal para su desarrollo está prácticamente congelado por las prácticas actuales.
No puedes seguir todas las reglas, todo el tiempo (YCFATRATT, o "rata gorda").
Me di cuenta del mensaje que le dejaste recientemente a un recién llegado. Recuerda no morder a los recién llegados . Si ves que alguien comete un error común , intenta señalarle educadamente qué hizo mal y cómo corregirlo. Si no sigue las normas, da un paso más y explica cómo cumplirlas, e intenta no depender solo de las plantillas de advertencia; la política exige dar la bienvenida a los recién llegados .
El primer mensaje que debe recibir un nuevo editor es un aviso de bienvenida, no una advertencia de reversión. Puede utilizar la plantilla {{welcome}} o activar Twinkle en Preferencias->gadgets para acceder a la lista de plantillas de bienvenida precargadas diseñadas para editores problemáticos, que son mucho menos incisivas que las plantillas sin formato. ¡Gracias!
Usando referencias
Una breve nota sobre la inserción de referencias. Al añadir un enlace externo, intenta utilizar la plantilla "Citar web", que formatea correctamente el enlace y lo añade a la sección Referencias. Puedes ver cómo utilizar la plantilla en la guía del usuario .
Asegúrese también de que la página externa que está utilizando sea una fuente confiable ; no todas las páginas son referencias válidas.
{{ efn }} se utiliza en cada nota al pie, junto con {{ notelist }} encima de la sección de Referencias, para crear notas explicativas. ( Hundimiento del RMS Titanic )
{{Tl|Example}} - El enlace de plantilla se utiliza para mostrar un nombre de plantilla como {{ Example }}
Ley de Poe sobre la parodia indistinguible de la cosa real ("sin un indicador claro de la intención del autor, las parodias de opiniones extremas serán confundidas por algunos lectores o espectadores como expresiones sinceras de las opiniones parodiadas")
http://reportcard.wmflabs.org (o la información más detallada en http://stats.wikimedia.org/EN/SummaryEN.htm que tiene *todos* los datos sin redacciones).
CatScan - Intersecciones de categorías
Laboratorios de herramientas (Fundación Wikimedia) https://tools.wmflabs.org/
Reparador de referencias de Reflinks - arreglar URLs crudas
páginas vistas
Herramientas wiki de Alanscottwalker
Buscar en el historial de una página las ediciones realizadas por un usuario en particular[14]
Lista de cambios realizados recientemente en páginas vinculadas desde una página específica [15]
Enumere los colaboradores de un artículo, clasificados por orden de actividad[16]
Encuentre imágenes para un artículo determinado, utilizando enlaces interwiki[17]
Encuentre qué páginas Wiki enlazan a un sitio en particular [18]
¿Qué páginas habéis editado tú y otra persona? [19]
Contribuciones de los usuarios en distintos proyectos [20]
Buscar en las páginas anteriores de Wikipedia [21]
" Gamasutra contrastó el nivel de críticas que una campaña debería esperar razonablemente con la cantidad de reacciones negativas recibidas de las comunidades en línea". [39]
Un colaborador de Forbes señaló que, si bien los argumentos coherentes y significativos contra "lo que está haciendo o cómo lo está haciendo" eran legítimos, las reacciones violentas y las amenazas no lo eran.[40]
“Durante el último año hemos visto varios casos en los que mujeres de alto perfil fueron objeto de una reacción similar, entre ellas la escritora de Bioware Jennifer Hepler, Aisha Tyler y Felicia Day”. [41]
para rellenar: Categoría:Incidentes de acoso en videojuegos
The Guardian http://www.theguardian.com/technology/2014/sep/01/como-atacar-a-una-mujer-que-trabaja-en-videojuegos
Acción del administrador
dialmove mantener
TEMA PRIMARIO vs SIGNIFICADO PRIMARIO
Acerca de la estructura y las costumbres del wiki de conocimientos de los lectores
significado de palabras comunes y modismos sh b tomados en cuenta para determinar el tema principal
páginas vistas suficientes para establecer el significado primario
-- sin umbral--falta la estadística de Wikt
Prueba de que las visitas a la página del nombre base están distorsionadas y no son proporcionales a la popularidad del tema: aquí
Brand New ha sido visto 121163 veces en los últimos 90 días.
Jesse Lacey ha sido visto 31078 veces en los últimos 90 días
Brand_New_discography ha sido visto 9731 veces en los últimos 90 días.
Your_Favorite_Weapon ha sido visto 18359 veces en los últimos 90 días.
Deja_Entendu ha sido visto 36532 veces en los últimos 90 días.
El_diablo_y_Dios_están_furiosos_dentro_de_mí ha sido visto 34364 veces en los últimos 90 días.
Daisy_(álbum) ha sido visto 18634 veces en los últimos 90 días.
Desambiguación: añadir una advertencia sobre la validez de las visitas a la página
Mide la cantidad de personas que accedieron a cada página, no los usuarios que quisieron leer sobre ella. Estos datos pueden estar correlacionados, pero son confiables solo en estas circunstancias.
El nombre base es una página de desambiguación.
No hay un modismo o palabra común en inglés -> no hay forma de saber si los lectores buscaron el tema o las palabras
No hay un aumento a corto plazo de popularidad como evento reciente en ninguna parte del mundo
(sólo si el evento es mundial y constante mostrará un aumento real del interés; de lo contrario, mide el interés de solo una pequeña cantidad de lectores)
páginas vistas
Argumentos
Usted pregunta: "¿Por qué se tomaría VSM como explicación de por qué un concursante tiene una ventaja en Q2 cuando Q2 contiene 2 miembros igualmente ponderados del espacio muestral 2 en ese momento, en Q2 sobre cualquier otra razón que no sea él mismo?" Hay dos razones:
1) no es cierto que "Q2 contiene 2 miembros con ponderación igual del Espacio Muestral 2 en ese momento en el tiempo"; debido a la forma en que se han seleccionado las dos puertas de un conjunto de tres puertas, los miembros del Espacio Muestral 2 no tienen ponderación igual.
2) El VSM responde a la pregunta que define el problema de Monty Hall, y la probabilidad ponderada igual de 1/2 es una respuesta a una pregunta diferente, no al problema de Monty Hall.
No es cierto que la solución al problema de Monty Hall sea un falso dilema. La formulación del problema nunca supone que sólo hay dos opciones; esta parte de tu razonamiento es un argumento falaz que planteas para desacreditarlo, pero no es un defecto de la solución original.
La pregunta que define el Problema de Monty Hall es: "¿Le conviene cambiar de estrategia?", que es lo mismo que "¿Es mejor cambiar siempre de estrategia que cualquier otra posible?". Esto no implica que "nunca cambiar de estrategia" sea la única estrategia posible, eso es algo que usted acaba de inventar. Es perfectamente posible comparar "cambiar siempre de estrategia" con "cambiar de estrategia cuando una moneda al azar lo indique".
En particular, si comparas esas opciones, el problema es equivalente a "¿Es la probabilidad de cambiar siempre mayor que la probabilidad de cambiar después de lanzar una moneda?", lo que significa "¿Es 2/3 > 1/2?". Como el primer valor es de hecho mayor que el segundo, la respuesta a la pregunta formulada en el problema es "sí". No puedo entender qué razón te ha llevado a creer que la estrategia de "cambiar siempre" no debería considerarse parte del problema, cuando es la pregunta la que define el problema en sí; ni por qué insistes en que "lanzar una moneda" es la única estrategia que debería usarse, cuando el problema pregunta explícitamente por una estrategia diferente.
Por supuesto, si cambias las condiciones iniciales, puedes llegar a conclusiones diferentes, pero entonces no estás resolviendo el mismo problema ni respondiendo a la misma pregunta. De tu razonamiento no se sigue que a la pregunta "¿te conviene cambiar siempre de opción?" debas responder con un "no", porque en el camino has cambiado a una pregunta diferente.
América, ese continente
Medios latinoamericanos con ediciones en inglés [45], tambien [46]
Gibraltar: indecisos. Cuando esta claro por contexto que hablan de un continente, claramente usan América. [47] `[48] 60 días americanos en Asturias
El primer papa americano, Vaticano. Papa viene de América. América = continente americano (y, a menudo, América = América Latina)
Cree un espacio de nombres para borradores de artículos cerca del espacio principal de artículos (no en Incubator ni en páginas de usuario). Primero en Article/UNSTABLE (?), luego adapte el software para que admita UNSTABLE:Article (prefijo U:)?.
Trate el contenido en UNSTABLE con las mismas reglas permitidas en Talk, pero donde el único contenido es una versión borrador del mismo tema.
WP:N, WP:NOT y WP:V (incluido BURDEN) son deseables, pero están exentos. El borrador funciona como un AfC colaborativo donde se pueden desarrollar versiones alternativas y mantenerlas por un tiempo sin correr el riesgo de que se borren instantáneamente. WP:PRESERVE y WP:IMPERFECT son los reyes.
Las buenas ideas encontradas en el borrador se pueden probar para verificar su cumplimiento con la política del espacio principal de WP e incorporarlas al artículo real cuando se consideren notables, verificables y neutrales.
El contenido eliminado en AfD podría ser INESTABLECIDO, cuando anteriormente se habría considerado valioso para la Incubadora.
El problema de la Incubadora no es que fuera una mala idea, es que era imposible encontrarla y participar. Si la hiciéramos más visible podríamos lograr los mismos objetivos.
Las normas de derechos de autor (incluida la NFCC) y las normas BLP deberían tener plena aplicación, al menos en el mismo grado en que se aplican actualmente en las páginas de discusión.
- Tiene sentido quitar todo de la vista para mantener el espacio principal ordenado, ya que es el escaparate de nuestro trabajo; pero el espacio de borradores no tiene esos requisitos, por lo que no es necesario limpiarlo tan a fondo; podemos ser más indulgentes y conservar las cosas por si acaso pueden ser útiles en el futuro. Ese es el espíritu de la política de conservación y lo que permite que funcione la forma Wiki de crear contenido. - "El espacio de artículos es eliminacionista, el espacio de borradores es inclusivo".
Discusión en toda la comunidad contra la expiración de los borradores en seis meses ("A menos que un borrador del espacio de usuario sea inaceptable para Wikipedia por razones no relacionadas con GNG (violaciones de derechos de autor, autopromoción, etc.), no tiene fecha de expiración y no tiene que cumplir con WP:GNG. Los borradores sin esperanza no deberían quedarse indefinidamente, pero los borradores con cierto potencial deberían poder quedarse").
RFC de borrador anterior
Lista de juegos de arte de ideas
Podemos seguir varios enfoques no excluyentes para mantener una lista, variando los criterios de inclusión, gestionando el crecimiento y discutiendo en la página de discusión. Las listas sólidas que son aceptadas por la comunidad tienen criterios de inclusión objetivos que son fáciles de evaluar, sin mucho lugar para el desacuerdo y son lo suficientemente estrictas como para dejar fuera de su alcance tantos elementos como los incluidos.
Las listas robustas que son aceptadas por la comunidad tienen criterios de inclusión objetivos que son fáciles de evaluar, sin mucho lugar al desacuerdo y son lo suficientemente estrictos como para dejar fuera de su alcance tantos elementos como los incluidos.
(En Art Games hemos luchado hasta encontrar un criterio equilibrado con) críticos y críticas como RS para cada artículo. Cobertura significativa = descripción detallada por al menos un R (más de la parte "pertenece/no pertenece"). La diferencia entre fancruft y enciclopédico radica en la existencia de críticos profesionales que revisan la obra.
Cuando la lista crece, un buen criterio de división permite seguir creciendo conservando una estructura útil.
Las listas de juegos de arte y juegos como forma de arte eran originalmente una única lista. Se dividió para proporcionar criterios de inclusión más claros para cada una. Se pueden dividir por subtema destacado (género) o por organización (año, país). Un grupo de elementos verificables pero no destacables se puede dividir como una lista complementaria si el grupo en sí ha recibido comentarios. Esto ayuda a mantener el tamaño de la lista manejable, lo que permite que cada tema crezca a un ritmo diferente sin desequilibrarla.
acumulación de entradas de candidatos (y rechazados) en la página de discusión
Requerir que cada entrada sea notable es necesario en listas creadas con fines de navegación (cuando el tema de la lista en sí no ha sido descrito como un grupo o colección), pero no es necesario cuando el tema es notable como grupo.
Cómo revisar la fiabilidad de una fuente controvertida
Paul Tassi http://yesikareyes.com/2012/04/12/tagw/ http://www.forbes.com/sites/insertcoin/2013/03/12/gears-of-wars-cliff-bleszinski-pushes- espalda-contra-los-criticos-sarkeesianos/
Tableta informática [1] [51] Algunos de los problemas aducidos son que los dispositivos existentes eran demasiado pesados para ser sostenidos con una mano durante períodos prolongados; tenían aplicaciones heredadas creadas para interfaces de escritorio que hacían que no se adaptaran bien al formato pizarra; y las características específicas del software diseñadas para soportar el uso como tableta, como teclados virtuales , tinta digital [2] y menús circulares no estaban presentes en todos los contextos. [3] [ ¿ fuente poco confiable? ]
Nivel 2 de semiprotección: cambios pendientes RFC https://en.wikipedia.org/wiki/User:Diego_Moya/Wikipedia:Pending_changes/Request_for_Comment_2014
Dos preguntas incómodas y centrales que nunca fueron respondidas: - ¿cómo la eliminación de los capítulos mejora el artículo? (por sí sola, sin recurrir a reglas) y - ¿cuál es la investigación creada (qué pensamiento se propone)?
NPOV - [ https://en.wikipedia.org/w/index.php?title=Talk:Zoe_Quinn&diff=626468725&oldid=626468165 ] gran criterio sobre neutralidad y conservación de fuentes por parte de Wnt
Ver más abajo Arquitectura de flujo de Wil Sinclair
¡Esta página contiene sólo 18 comentarios únicos! Y tiene 6997 píxeles de alto. Eso significa 388 píxeles por comentario. Diego ( discusión ) 21:00, 14 de octubre de 2013 (UTC)
Lin - Estudio de espacios en blanco de 2004
Sin mejora de rendimiento, mayor satisfacción: con espacios en blanco alrededor de encabezados y títulos Chaperro, Shaikh y Baker, 2005 (pdf)
Vista aérea de los archivos VG [52]
Espacio en blanco http://boagworld.com/design/why-whitespace-matters/
Experimento con modelo de sangría de hilo: [53] (ver original)
Con imagenes
imagen 2
Tabla de contenidos de flujo
Tabla de contenidos, paginación y archivo
https://trello.com/c/1Mdiy4Fn/687-table-of-contents-new-draft https://trello.com/c/D07zN08H/334-archiving-pagination
"Community_areas es muy poderosa para nosotros. Si el objetivo es que Flow reemplace las páginas de discusión de artículos, entonces la gente tendrá expectativas muy altas de Flow como espacio de trabajo".
Editar los comentarios de otras personas: ¿un nuevo ángulo?
* El segundo artículo de la categoría Geografía es Greater Boston , con 33785 visitas en los últimos 90 días (aprox. 1/10 del tema principal). [56] El nombre proviene originalmente de Boston, Lincolnshire , cuyo artículo obtuvo 19973 visitas (1/16). [57]
** Hay un artículo enlazado desde la página de desambiguación, Deportivo de La Coruña con 61719 visitas,[58] pero comúnmente se lo conoce como "Depor", no "A coruña".
***Aquí tenemos datos de las redirecciones de los usuarios que llegan a la página de desambiguación al buscar el término "América"
Valores intangibles en el conocimiento libre
Atención_economía#Intangibles
Artículo de The Edge "MEJOR QUE GRATIS" Por Kevin Kelly publicado el 5 de febrero de 2008
0-Confianza.
Inmediatez: acceso prioritario, entrega inmediata
Personalización: hecha a tu medida
Interpretación - apoyo y orientación
Autenticidad: ¿Cómo puedes estar seguro de que es el producto auténtico?
Accesibilidad: donde sea y cuando sea
Encarnación - libros, música en vivo
Mecenazgo - "pagar simplemente porque te hace sentir bien",
Facilidad de búsqueda: "Cuando hay millones de libros, millones de canciones, millones de películas, millones de aplicaciones, millones de todo lo que solicita nuestra atención (y la mayor parte de ello gratis), ser encontrado es valioso".
He estado trabajando en un nuevo borrador que incluye las preocupaciones de la oposición a la versión en la RfC. Estoy tratando de enfatizar las medidas viables y los criterios de decisión por sobre las medidas subjetivas (si un tema "merece" un artículo o no) que siempre serán una cuestión de opinión personal y son propensas a producir división. Creo que la oración inicial (" tener un artículo independiente en Wikipedia es una cuestión de estilo ") es más segura que la propuesta anterior (" no se requiere una página independiente para cada tema "), que estaba orientada a no tener el artículo.
Además de las ideas anteriores sobre cuándo se debe fusionar un tema importante, he añadido una nueva sección con razones para mantener el artículo independiente. Espero que estos criterios, enumerados en viñetas, estimulen el debate directo y faciliten así los acuerdos y la creación de consenso.
No estoy seguro de cómo proceder para presentar un nuevo borrador ahora que el anterior es la base de la convocatoria de propuestas y ya muestra cierto apoyo (así como oposición). Creo que es común primero refinar la nueva propuesta hasta llegar a un punto medio razonable y luego iniciar una encuesta informal para cada propuesta de modo que se puedan establecer preferencias claras.
Cuando un tema satisface los estándares de notabilidad, tener un artículo independiente en Wikipedia es una cuestión de estilo y de cómo se presenta mejor la información disponible. Un tema notable se puede cubrir mejor como parte de un artículo sobre un tema más amplio, incluyendo el contexto que se perdería en una página separada. Por el contrario, cuando hay suficiente información para crear un artículo bien equilibrado , una página separada proporciona más espacio para cubrir el tema en profundidad. Las pautas de notabilidad específicas de cada tema y las páginas de consejos de WikiProject pueden proporcionar información sobre cómo tomar estas decisiones editoriales en áreas temáticas particulares.
Temas destacados como parte de artículos más extensos
Un tema puede describirse en una pequeña parte de un artículo más amplio cuando no hay suficiente contenido para un artículo de clase inicial . En esa situación, se pueden utilizar páginas de redirección y desambiguación para dirigir a los lectores que buscan dichos temas a los artículos y secciones correspondientes dentro de ellos. El tema debe ser relevante para el contenido del artículo de destino.
A decision to cover a notable topic only as part of a broader page does not in any way disparage the importance of the topic, as it provides the reader with the wider picture and better explains how the subject relates to the main topic. This is a good solution for topics that are notable but fall under What Wikipedia is not, such as news reports or catalog tables of reasonable size.
Several related notable topics can be collected into a single page, where the relationships between them can be better appreciated than if they were each a separate page (as at Music of the Final Fantasy VII series).
A future event may clearly be notable before it happens (such as the 2020 Summer Olympics), but if information is scarce at the time, coverage may instead be better suited to a larger encompassing article (see also WP:CRYSTAL).
A subject that is notable, but for which it is unlikely that there ever will be a lot to say, may best not be made a permanent stub.
Notable topics as standalone pages
Deciding whether a separate article is needed is often difficult for a notable topic with few reliable sources, or for which sources provide a small amount of distinct information. There are some cases where covering such topic with a short article is still a good idea:
Enough references describing the topic may exist, and the article is short only because the sources have not been included yet. A well placed stub for a topic with potential to be expanded can entice editors to add content and complete the article with the right format and structure, making it easier than creating the article anew.
There are cases where many similar notable topics exist and they cannot be collected into a single page, since the resulting article would be too long. A viable option is creating a new list or category for the broad-concept topic and linking the individual articles from it. See Category:Restaurants in New York City for an example.
Placing the content of a notable topic under a wider article can provide undue weight to it. That can happen with fringe theories or lesser episodes in a biography, in special for biographies of living persons. In those cases, a standalone article for the notable topic is preferred, as the content is likely to be removed from the main article.
Short articles should provide enough context beyond a summary or simple definition in order to explain how the topic has impacted the world, or how it was received by people that wrote about it. The reason for a topic's noteworthiness should be established, or at least introduced, so that a reader with no previous knowledge of the topic can get a rough understanding of it. This can be done including attributed value judgments from experts in the field such as reviews, critiques and academic studies. Focusing on the quality of coverage, rather than its quantity, can help to ensure that the significant content required to write a standalone article is available.
Wikipedia is a digital encyclopedia, and the amount of content and details should not be limited by concerns of article size. This means that all the reliable sources can be potentially included as long as they are relevant to a topic. If many independent sources provide a neutral description of the same details, the details are deemed notable and a new spinoff article can be created to hold them. A brief description in summary style can link to it from the main article, providing the same context that would be available if the standalone article didn't exist.
FLOW points of failure
Problems created by creating Wikipedia edit tools that not support a wiki platform:
no templates - new templates rebuilt from scratch
no transclusion - only the fixed structure of boards
no free-flow refactoring, only pre-defined use cases
Talk pages consultation 2019 finally some thoughts in the correct direction
Moya's pyramid of human-computer interaction tools
Trascendency: thriving on the attainment of far-reaching goals and aspirations; an inherent need to evolve, improve and get better. (Paraphrased from [61])
How traffic actually works - "when there is excess capacity in the road behind you, i.e., the flow rate is below the theoretical maximum and the occupancy is below the critical threshold where people start caring about following distance. You might know whether such a region exists behind you because you just drove through it. So in that situation, it is actually beneficial to try to smooth out the traffic wave by driving slower as you approach it."
To Do
3D agent-based games http://sgda.cs.colorado.edu/arcade/sites/all/modules/drupal_modules/ristretto3d/Ristretto3D/public/hourofcode.html?path=http://sgda.cs.colorado.edu/arcade/sites/default/files/Arcade%20Projects/Hour%20of%20Code3/AgentCubes/Open%20Arcade/0186845d-01c3-4080-99b1-87e16bbb6b2a/currentProject/0186845d-01c3-4080-99b1-87e16bbb6b2a&nid=231733&edit=true&hour_of_code=true&edit=true
Update content with animations: medium.com/design-ux
Why revolutions don't work
(prompted by [63])
That "fight for your lifes" rhetoric is number 1 tool in the dictator's manual to get people fight in their place, either the dictator-in-place or the dictator-wannabe in the opposition. This is the way that leads to war, in which everybody looses except those planning for it and encouraging it in order to make economic benefit from the strife.
Dictators have power because they're at the peak of a wide social network; the way to fight them is to remove their bases. So you don't negotiate with them, you convince their followers so that they drop their support; and you need negotiation to achieve that. Instead, if you simply rise the stakes you make the support from the basis stronger; the end result of a violent revolution is a more solid dictatorship from whomever manages to win the armed conflict.
FRP explained well
[64]
And my own take:
Mail 1 - the elevator pitch
The Functional Reactive paradigm provides better abstractions for
concurrency than imperative code - futures, promises and observables are
at a way higher level than locks and semaphores, and in many cases allow
writing complex asynchronous code in a pure functional way. For the rest
of cases, you can add explicit state and transform it into an agent-based
model, which is essentially OOP parallelism done right.
So yes, I think a high-level paradigm that simplifies synchronization can
make complex parallel tasks easier to program and reason about. I've seen
some examples in action, of which Espresso Logic is an awesome case.
...
That's like saying that building a library for P2P communication is trying
to reinvent the TCP/IP protocol. Sometimes you need to look your old tools
from a new perspective to adapt it for new, complex use cases that were
impossible to tackle from a low level perspective.
Several mayor players as well as multiple small ones are adopting tools
from FRP for their libraries and software stacks, and knowledge about the
paradigm is spreading through official documentation, MMO courses and the
blogosphere - which makes corner cases shallow, and deepens our
understanding of the paradigm.
Mail 2 - composition and perspective
Insight: in GUI, observables and composition of streams are to events as OOP inheritance was to GUI layout and structure. The latter allowed to build components (widgets), and the former allows to build behaviors, which are reusable components of interaction ("actlets"?).
I have arrived to the following intuitive way to explain why FRP and other dataflow paradigms matter.
Think first of GUIs and object-orientation: class inheritance allows you to create a hierarchy of widgets with more and more specialized behavior, and reuse the parts of code that handle common tasks like layout and redrawing. Now, you could think of this as a very complicated way to draw squares on a canvas, or realize that it breaks the GUI problem in 1) simple encapsulated components plus 2) simple glue code to bind them.
Now, I've come to believe that dataflow programming allows you to do the same thing with distributed computations and asynchronous communication. Change in the system is seen as a stream of values instead of a chain of events, which allows you to create compositions and transformations of events - in the same way that you would build complex dialogs by composing and transforming widgets in a GUI.
This complex composition of events is very difficult to reason about in imperative code, but in FRP it takes the form of reusable "behavior components" that are programmed in a simple way (clasic stateless functional composition). The hardwired inputs and outputs between static widgets and/or dynamic behaviors are automatically updated by the language runtime in the lazy, efficient way you describe above.
Does all of this makes any sense?
The best thing is that, thanks to recent theoretical advances (combined with the ever increasing computational power of new hardware), FRP doesn't seem to be that inefficient any more; and I think that's why it's beginning to spread everywhere you look at. Though it will require a lot of training on old-school developers, that's for sure!
Mail 3 - the engine vs the series of tubes
This morning I've found this list of examples in the Elm language, a FRP language which compiles to HTML+CSS+Javascript:
http://elm-lang.org/Examples.elm
The Intermediate section include a bunch of examples that are considered quite difficult in classic functional programming (video games & animation), but FRP seem to handle those very well.
The Mario and Turtle examples follow a rather intuitive structure - declare your variable structures, then define your methods for behavior (with a very imperative flavor to them - first find the image for the canvas, then rotate it, then place it on its coordinates), and connect the input devices to the model logic.
The trick is that the behaviors don't really destroy the previous value of their variables. You can use a variable as a scalar (e.g. "the x and y coordinates *right now*") but it's often useful to think of them as collections.
Each variable contains an infinite vector with all values that the variable takes during runtime, generated from one stream or a combination of them ("all mouse clicks or keyboard presses"). You can access past and future values or apply filters over the whole collection, and the efficient language VM will make sure that the current value of the stream is propagated to whatever part of the program where it's used (such as updating the screen).
Expressing the same in an imperative language would require building a state machine that keeps track of what has happened before in the sequence of values for the variable, or storing and updating in memory the collection of previous values by yourself. With FRP, those common programming aspects are encapsulated and easy to express in the language.
Of course, the glue code will take a totally different shape; in the imperative paradigm, you think of the language virtual machines as very complex state machines that consume their inputs, update their internal state by destroying the previous one, and spit new generated values by changing the state of the output devices (i.e. changing the world itself). Glue code takes the form of sequential subroutines that give orders to the machine as to what state to go next, and the pass of time is represented by moving to the next instruction in the sequence.
Instead, in dataflow languages, the virtual machine is a spreadsheet-like environment that allows you to draw directed graphs that connect components together (in a spreadsheet you can see the graph by drawing arrows between each cell and all its dependencies). Program execution consists of connecting the inputs to a data storage and waiting for the results to appear at the opposite side, and the pass of time is represented by accessing values that are positioned later and later in their streams.
Criticism
"But it's just streams, not a new thing at all"
It depends on perspective. If you see it as a tacked-down library on top
of an interactive language, of course it's smallish. But from that
perspective, OOP is just high-order functional programming plus cells, so
it's not a big thing either, true? It's "just a big name for the concept
of state".
The thing with programming paradigms is not that they introduce whole new
constructs, it's the way they make you think about them. Any paradigm will
reuse the same old basic elements available in all previous programming
styles, and explain them in a new way that makes sense.
"It can't be used everywhere, so it's not a paradigm" (plus, state machines are the same thing).
But that's the thing, if you program in RFP you *don't have* state
machines, it's streams all the way down. If you study RFP as a
mathematical way to describe program execution, like PL people do, it's a
whole new theoretical construct, with its own set of axioms. The formal
semantics of an RFP language will look different than those from an
imperative language, which look different than those from a functional or
a logic language.
Surely you *can* think of the language implementation as being a
program written in a different, old paradigm (which negates any benefit
provided by the new, btw), but you don't *need* to; any Turing-complete
language can be transformed into any other. I've seen languages for
programming micro-controllers based on the lambda calculus, with no notion
of state, if that's your thing.
You wouldn't use dataflow programming for calculating a concurrent
constraint satisfaction problem (or maybe you would, but it will be more
difficult), as you wouldn't use a constraint logic solver to program a
platformer game. When you find a paradigm that is well suited to the
problem to solve, there's little use in thinking of how that paradigm
translates into a different, less adequate paradigm.
See [1] for how different paradigms relate to each other (taken from [2]);
the difference from one paradigm to another is always minimal, but they
make the language feel completely different.
[1] http://en.wikipedia.org/wiki/User:Diego_Moya/File:Programming_paradigms.svg [2]
"Programming Paradigms for Dummies: What Every Programmer Should Know",
http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf