View text source at Wikipedia

User:Diego Moya

http://stats.grok.se/en/latest90/Greater_Bostona.k.a. Dialmove. Protecting SNOWFLAKEs since January 2012.


Oh shit, they keep the User pages of deceased Wikipedians as a memorial. I'll need to do cleanup one of these days.


Watching for:

mw:Winter is coming.

Learning Wikipedia:New pages patrol.

Trout this userWere this user to act in a foolish, trollish, or dickish way, they are open to being slapped with a large trout.
Wikipedia:Babel
esEste usuario tiene el español como lengua materna.
en-3This user can contribute with an advanced level of English.
Search user languages
This user tries to do the right thing. If they make a mistake, please let them know.
This user is a participant in WikiProject Computing.
CSThis user is a participant in WikiProject Computer science.
This user rescues articles for the Article Rescue Squadron.
This user is a participant in WikiProject Human–Computer Interaction.
This user is signed up for the Feedback Request Service.
This user enforces a zero tolerance policy against newbie biting.
UAThis user supports the User Advocacy effort.

Inclusion criteria for Lists and Stand-alone lists

Searches

[edit]

Proposals

[edit]

Licenses

[edit]
Multi-licensed with all versions of the Creative Commons Attribution Share-Alike License
I agree to multi-license my text contributions, unless otherwise stated, under Wikipedia's copyright terms and the Creative Commons Attribution Share-Alike license version 1.0, version 2.0, version 2.5, version 3.0, version 4.0 and all future versions of the Creative Commons Attribution Share-Alike license. Please be aware that other contributors might not do the same, so if you want to use my contributions under the Creative Commons terms, please check the CC dual-license and Multi-licensing guides.
Dual licensed with the GNU General Public License
I agree to additionally license any of my contributions (for which I hold the copyright) under the GNU General Public License (GPL) version 2. Please be aware that other contributors might not do the same, so if you want to use my contributions under the GPL terms, please check the Multi-licensing guides.
Licensing rights granted to Wikimedia Foundation
I grant non-exclusive permission for the Wikimedia Foundation Inc. to relicense my text contributions under any copyleft license that it chooses, provided it maintains the free and open spirit of the GFDL. This permission acknowledges that future licensing needs of the Wikimedia projects may need adapting in unforeseen fashions to facilitate other uses, formats, and locations. It is given for as long as this banner remains.


Wikidata

[edit]

Dbpedia

[edit]

Semantic - generic

[edit]

Wikidata Tools

[edit]

RFCs

[edit]

Wikipedia_talk:User_pages#Should_old_user_space_drafts_have_an_expiration_date.3F. Drafts have no expiration date

Essays to write

[edit]

Articles I'm interested in

[edit]

I'm (mostly) proud of my cleanup work [5] in the Monad (functional programming) article (before [6], after [7]).

Other articles to which I've significantly contributed:

Improving lead sections

[edit]

Working hard to make lead sections understandable at least in these articles:

Plenty others...

Community - my own templates

[edit]

Teoría de juegos-game theoretic analysis of Wikipedia conflict by User:Volunteer_Marek/gt.

Consensus discussions

[edit]

Zero tolerance 2 newcomers bite

[edit]

anti-bite templates:

subst:Uw-bite

subst:Uw-npa1

subst:Uw-npa2

subst:Uw-agf2

subst:Uw-notcensored1

subst:Uw-own3


Warning text:

Information icon I noticed the message you recently left to a newcomer. Please remember not to bite the newcomers. If you see someone make a common mistake, try to politely point out what they did wrong and how to correct it. If they fail to follow policy, take the extra step to explain how to comply with the rules, and try not to rely only on warning templates; being welcoming to newcomers is mandated by policy.

The first message a new editor should receive is a Welcome notice, not a revert warning. You can use the {{welcome}} template, or activate Twinkle at Preferences->gadgets to access the list of pre-populated welcome templates tailored for problematic editors, that are much less bite-y than the raw templates. Thanks!

Using references

[edit]

A brief note about inserting references. When adding an external link, please, try to use the "Cite web" template, that properly formats the link and adds it to the References section. You can see how to use the template at the user guide.

Also make sure that the external page you're using is a reliable source; not all pages are valid references.

[edit]

Essays

[edit]

Wikiproject pages

[edit]

To create an anchor target without a section heading, you can use a the {{anchor}} template or a span: <span id="anchor_name"></span>.

Help:Wikipedia: The Missing Manual

Wikipedia:Writing better articles User Warning Templates Wikipedia:Map [Mapa Wikipedia España]

***********************

Templates

[edit]
             Wikipedia:Boilerplate text
Discussion not directly related to this thread subject
  • mucho texto oculto
  {{Reflist|refs=
      <ref name="refname1">content1</ref>
      <ref name="refname2">content2</ref>
   }}

Discussion logs in talk pages

[edit]

Sources

[edit]

Reliable Sources search engine Situational Sources for Video Games

Horror Films reliable sources


http://www.ii.uam.es/~dmoya/index.html


Preferences

[edit]

[User:Diego_Moya/vector.js vector javascript page]

Cite bots and search tools

[edit]

Insert References tools:

Old toolserver ([9] [10])

Setup - configuracion

[edit]

SMS Cheatsheet

[edit]

Knowledge - links

[edit]


Tools (new)

[edit]

Wikipedia:Tools - todos los enlaces

[13]

Tools Labs (Wikimedia foundation) https://tools.wmflabs.org/

Wiki tools by Alanscottwalker

[edit]

Scripts

[edit]

Half baked

[edit]

My half baked articles-

Notes to self

[edit]

http://debburn.alioth.debian.org/FORK

Ammunition for disambiguation/move/PRIMARYTOPIC guidelines

[edit]

What is confusing readers? Disambiguation can be done wrt:

NFC bots are out of control

[edit]

To do

[edit]

Feminism & harassment

[edit]

Admin action

[edit]

PRIMARYTOPIC vs PRIMARYMEANING

[edit]
-- no threshold
-- lacking Wikt stat


Disambig: add a warning about the validity of page views

it measures the number of people that accessed each page, not the users who wanted to read about it. These may be correlated, but reliable only in these circumstances

base name is a disambiguation page

no English language common idiom or word -> no way to know if readers looked for the topic or the words

no short term rise in popularity recent event anywhere in the world

(only if the event is world-wide and steady it will show a real rise of interest - otherwise it measures the interest of just a small amount of readers)


Argumentos

[edit]
You ask: " Why would one take VSM for an explanation of why a contestant has an advantage at Q2 when Q2 contains 2 equal weighted members of the 2 Sample Space at that moment in time, at Q2 over any other reason than itself." There are two reasons:
1) it is not true that "Q2 contains 2 equal weighted members of the 2 Sample Space at that moment in time"; because of the way that the two doors have been selected from a set of three doors, the members of the 2 Sample Space are not equally weighted.
2) The VSM answers the question that defines the Monty Hall Problem, and the 1/2 equal weighted probability is an answer to a different question, not to the Monty Hall Problem.


It is not true that the solution to the Monty Hall Problem is a false dilemma. The formulation of the problem never assumes that there are only two options, this part of your reasoning is a strawman argument that you set up in order to discredit it, but it is not a flaw in the original solution.


The question that defines the Monty Hall Problem is, "is it to your advantage to switch your choice?", which is the same as "Is it better to always switch than any other possible strategy?" This does not imply that "never switch" is the only other possible strategy, that is something that you just made up. It is perfectly possible to compare "always switch" with "switch when a random toss coin says so".


In particular, if you compare those options, the problem is equivalent to "Is the probability of always switching higher than the probability of switching after a toss coin?", which means "Is 2/3 > 1/2?". As the first value is indeed higher than the second, the answer to the question formulated in the problem is "yes". I can't possibly fathom what reason has led you to believe that the "always switching" strategy should not be considered as part of the problem, when it is the question that defines the problem itself; nor why you insist that "toss a coin" is the only strategy that should be used, when the problem explicitly asks about a different strategy.
Of course if you change the initial conditions, you can reach different conclusions; but then you are not solving the same problem, nor answering the same question. From you reasoning it does not follow that "is it to your advantage to always switch your choice?" should be answered with "no", because along the way you have changed to a different question.

America, ese continente

[edit]

documented controversy

[edit]

Statistics

[edit]


Ideas for WP:UNSTABLE

[edit]
  1. Create a namespace for draft articles near the main article space (not Incubator, not User pages). First at Article/UNSTABLE (?), later adapt software to support UNSTABLE:Article (prefix U:)?.
  2. Treat the content at UNSTABLE with the same rules allowed at Talk - but where the only content is one draft version of the same topic.
  3. WP:N, WP:NOT and WP:V (including BURDEN) are desirable, but exempt. The draft works as a collaborative AfC where alternate versions can be developed and kept for a while without risking instant deletion. WP:PRESERVE and WP:IMPERFECT are king.
  4. Good ideas found in the draft can be tested for WP mainspace policy compliance, and incorporated into the true article when found notable, verifiable and neutral.
  5. Content deleted at AfD could be UNSTABLEd, when previously would have deemed valuable for the Incubator.
  6. The problem of the Incubator is not that it was a bad idea, is that it was impossible to find and participate. By making it more visible we could achieve the same goals.
  7. Copyright rules (including NFCC) and BLP rules should have full enforcement, at least to the same degree that they are currently enforced at talk pages.

-PRODding everything out of view makes sense to keep the main space neat, as this is the showcase of our work ; but the Draft space doesn't have those requirements, so it's in no need of being cleanud up so thoroughly - we can be more lenient, and keep things just in case they may be useful in the future. That's the spirit of Preserve policy and what allows the Wiki way of building content to work. -"Article space is deletionist, Draft space is inclusionist".

Ideas art games list

[edit]

We can follow several non-exclusive approaches to maintain a list, ranging the inclusion criteria, handling growth, and discussion at the talk page. Robust lists that are accepted by community have objective inclusion criteria that are easy to assess, without much place to disagreement, and are strict enough to leave as many items outside is scope as those included.

The lists for art games and games as an art form were originally a single list. It was split to and provide a clearer inclusion criteria for each. They can be split by notable subtopic (genre) or by organizational (year, country). A group of verifiable but not-notable items can be split as a companion list if the group itself has received commentary. This helps to keep the list size manageable, allowing each topic to grow at a different rate without making it unbalanced.

Female VG characters

[edit]

User:Diego Moya/Female VG characters

**Wikipedia:Article_Incubator/List_of_female_video_game_characters_by_role - Incubated

Tropes - direct coverage

[edit]

Sarkeesian direct coverage

[edit]

TV Tropes NC

[edit]

Done

[edit]

Watches

[edit]

Discussions

[edit]

Flow

[edit]

http://ee-flow.wmflabs.org/wiki/Sandbox

http://naldzgraphics.net/design-2/11-reasons-why-white-spaces-are-good-in-graphic-design/


collaborative editing and structure

Lapis parser rule for Wikipedia Talk discussions

[edit]


Thread indentation model experiment

[edit]

Flow TOC

[edit]

TOC & pagination & archiving https://trello.com/c/1Mdiy4Fn/687-table-of-contents-new-draft https://trello.com/c/D07zN08H/334-archiving-pagination

Notifications Wikipedia_talk:Notifications/Archive_5#Granularity Wikipedia:Village_pump_(idea_lab)#Can_we_have_a_color_scheme_for_the_notifications_count.2C_please.2C_and.2C_if_not.2C_perhaps_some_other_color_than_red.3F https://bugzilla.wikimedia.org/show_bug.cgi?id=56476 Wikipedia_talk:Notifications#Two_kinds_of_notifications

Enchanced scratchpad vs Forum boards

Document-oriented workflow


My replies to Flow threads

[edit]

My comments at the portal: [54]

Wikimedia list

Other people's replies

[edit]

Latest

[edit]

https://trello.com/c/1Mdiy4Fn/687-table-of-contents-new-draft


Adopted draft

[edit]

Primary? topics

[edit]
Ambiguous term Currently a primary topic? Most visited Second most visited Ratio first/second Relation between two most visited topics
Boston (disambiguation) Yes Boston, Massachusetts 327818 visits Geography Boston (band)*

98347 visits Entertainment

3.33 Second topic took its name from the most visited
Chicago (disambiguation) Yes Chicago, Illionis 457522 visits Geography Chicago (band) 116813 visits Entertainment 3.9 Second topic took its name from the most visited
Richmond No Richmond, Virginia 95326 visits Geography Richmond, London 26575 visits Geography 3.5 US place took name from UK place
A Coruña (disambiguation) Yes A Corunha** 43830 visits Geography Province of A Coruña 2761 visits Geography 15.8 Second topic (the province) took name from first (the city)
Lorca No Federico García Lorca 54165 visits Author Lorca, Spain 3354 visits Geography 16.14 Surname originates from the city
America No US (country)

32157 visits***

Americas (continent)

7898 visits***

4.07 First topic took name from the second

* The second article in the Geography category is Greater Boston, with 33785 visits in the last 90 days (aprox. 1/10 the main topic). [56] The name originally came from Boston, Lincolnshire, whose article got 19973 visits (1/16). [57]

** There's an article linked from the disambiguation page, Deportivo de La Coruña with 61719 visits,[58] but that's commonly referred to as "Depor", not "A coruña".

*** Here we have data of the redirects from users arriving to the disambiguation page by searching for the term "America"

Knowledge

[edit]

Intangible values in Free knowledge

[edit]

Attention_economy#Intangibles The Edge Article "BETTER THAN FREE" By Kevin Kelly published February 5, 2008

0-Trust.
  1. Immediacy - priority access, immediate delivery
  2. Personalization - tailored just for you
  3. Interpretation - support and guidance
  4. Authenticity - how can you be sure it is the real thing?
  5. Accessibility - wherever, whenever
  6. Embodiment - books, live music
  7. Patronage - "paying simply because it feels good",
  8. Findability - "When there are millions of books, millions of songs, millions of films, millions of applications, millions f everything requesting our attention — and most of it free — being found is valuable."


Stored value

[edit]

http://www.nirandfar.com/2012/11/the-network-effect-isnt-good-enough.html

Elements of a viral meme

[edit]

S.T.U.P.I.D. users!

[edit]

[59] Or maybe they're just...

Ramblings

[edit]

[60]

56-bit_encryption Alef_(programming_language)


I've been working on a new draft, include the concerns from the opposition to the version in the RfC. I'm trying to emphasize actionable measures and decision criteria over subjective measures (whether a topic "merits" an article or not) that will always be a matter of personal opinion and are prone to produce division. I believe the opening sentence ("having a standalone article on Wikipedia is a matter of style") is safer than the previous proposal ("a standalone page is not required for every topic"), which was geared towards not having the article.

In addition to the previous ideas of when a notable topic should still be merged, I've added a new section with reasons for keeping the standalone article. I hope that these criteria, listed as bullet points, should stimulate direct discussion and thus facilitate agreements and consensus-building.

I'm not sure how to proceed to introduce a new draft now that the previous one is the basis for the RfC, and it's already showing some support (as well as opposition). I think it's common to first refine the new proposal to a sensible middle ground and then start a straw poll for each proposal so that clear preferences can be stated.

Draft 4

[edit]
Standalone pages for notable topics
Shortcuts

When a topic satisfies the notability standards, having a standalone article on Wikipedia is a matter of style and how the available information is best presented. A notable subject can be covered better as part of an article for a broader topic, including context that would be lost on a separate page. Conversely, when there is enough information to create a well balanced article, a separate page provides more room to cover the topic in depth. Subject-specific notability guidelines and WikiProject advice pages may provide information on how to make these editorial decisions in particular subject areas.


Notable topics as part of larger articles

Further information: Wikipedia:Merging

A topic can be described in a small part of a wider article when there is not enough content for a start class article. In that situation, redirection pages and disambiguation can be used to direct readers searching for such topics to the appropriate articles and sections within them. The topic should be relevant to the content of the target article.

  • 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

Further information: Wikipedia:Summary style and Wikipedia:Content forking

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

[edit]

Problems created by creating Wikipedia edit tools that not support a wiki platform:

Talk pages consultation 2019 finally some thoughts in the correct direction

Moya's pyramid of human-computer interaction tools

[edit]

Trascendency: thriving on the attainment of far-reaching goals and aspirations; an inherent need to evolve, improve and get better. (Paraphrased from [61])


"Human2Human computer-mediated interaction":

Knowledge model Tools (Known) outcomes
Group decisions Masive "big" data analysis, consensus-building protocols Tribes, mob rule, hive mind, Gaia, war
Semi-automated politics Cryptography. Hacking tools. Search engines. IBM Watson. Complex event processing[62] Cyber war. Bot-nets. P2P content sharing. Wikipedia. TV tropes.
Augmented intellect Anything shown at the mother of all demos. Wikiprojects. Knowledge markets like About.com and Quora.

"Human-computer interaction"

Data model Data entry tool State evaluation tool
?
Inferred concepts Deep learning processes Bret Victor's feedback-based programming environment
Ontology Ontology browser. Wiki platform. WYSIWYM
Markup language Visual editor WYSIWYG
High-level interpreted language Text editor + Intellisense-like API autocompletion IDE + debugger
Low-level compiled language Text editor IDE + debugger
Machine instructions Keypad Hex editor / disassembler
Binary code Switches LEDs
Electronic signals micro controller + data bus? oscilloscope or logic analyzer

web tools

[edit]

http://yeoman.io/about.html http://www.zingdesign.com/bootstrap-3-as-a-web-development-workflow-tool/

Traffic jam physics

[edit]

To Do

[edit]

Why revolutions don't work

[edit]

(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

[edit]

[64]

And my own take:

Mail 1 - the elevator pitch

[edit]

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

[edit]

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"?).

http://subbot.org/coursera/reactive/callbacks.png http://subbot.org/coursera/reactive/howtodobetter.png


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

[edit]

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

[edit]

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.

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/File:Programming_paradigms.svg [2] "Programming Paradigms for Dummies: What Every Programmer Should Know", http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

Subpages

[edit]
Three initial configurations of the game. In two of them, the player wins by switching away from the choice made before a door was opened.
A different selection process, where the player chooses after a door has been opened, yields different probabilities.
  1. ^ Making Things Easier with Tablet computing?
  2. ^ "Exploring ink in OneNote".
  3. ^ Opinion article by Frank Spillers. "Making Things Easier with Tablet computing?".