Talk:Brainfuck/Archive 2

Archive 1

Archive 2

practical use

The article says

It is a Turing tarpit, designed to challenge and amuse programmers, and is not suitable for practical use.

I don't think this is true at all. Many other programming languages have been proven to be turing complete by implementing a brainfuck interpreter in it. Here at university, on irc in programming channels, forums, mailing lists, everywhere you very often read as an answer to "is xyz turing complete?" "write a brainfuck interpreter in it"

That's not practical use, it's theoretical use :) DanielCristofani (talk) 23:23, 12 September 2011 (UTC)

Writing an interpreter for a language is not, by any stretch of the imagination, theoretical use. It demonstrates that brainfuck is easy to interpret, which is probably as far from a Turing tarpit as you can get. It is a simple, albeit unusual language: that is not how you describe a tarpit. Many things may be hard to program in brainfuck due to the lack of programmer niceties and the need to reinvent every wheel you'd normally have in a non-esoteric language, but it is not Malbolge and it is not a Turing tarpit. A tarpit would be a language that, though Turing complete, is either heavily reliant on state commands or bereft of features that are simple and easy to understand but loaded with all that is inconvenient and convoluted. — Preceding unsigned comment added by 108.203.162.123 (talk • contribs)

•Turing-completeness is a concept in computability theory. Writing a brainfuck interpreter to prove facts of computability theory, such as that language xyz is Turing-complete, is making a theoretical use of brainfuck. Writing a program in brainfuck to perform a useful computation would be making practical use of brainfuck.

•"Turing tarpit" is generally defined not in terms of the difficulty of implementing a language, nor in terms of complexity, but in terms of the difficulty of writing substantial programs in the language. By the usual definitions, brainfuck definitely qualifies. (I don't think anyone said it was Malbolge.) DanielCristofani (talk) 14:30, 4 February 2015 (UTC)

BF in evolutionary computation

Given that we have an external link to Nanopond, would it be reasonable to write a brief section about how and why BF gets used for that (and similar) uses? Michael Ralston 07:47, 24 February 2006 (UTC)

I think that would make sense if brainfuck were a useful language for evolutionary computation, but I don't think it is. I will have a look at Nanopond and see what kinds of things have evolved, though. DanielCristofani 00:42, 26 February 2006 (UTC)

It works quite well for examining simple diversity - it's a simple enough language that it's not difficult to make a VM that never has illegal operations, and the limited execution space helps quite a bit as well. Michael Ralston 01:00, 26 February 2006 (UTC)

External Links

I am just wondering if the Interpreter I once wrote in PHP is worthy of a link. It does have much use different from the other links, but it just offers an overview of what happens through your application. Here is the link. I original made it due to the fact I had problems overviewing my own brainfuck applications, so I assumed I could fix it by getting some verbose. --Svippong 00:19, 25 March 2006 (UTC)

Sure. I think it would be a nice addition. —mako 22:06, 25 March 2006 (UTC)

Lowercase

None of the web references seem to use this affectation of lowercasing "brainfuck" at the start of a sentence. The mere fact that it's not capitalized in the middle of a sentence, in spite of being a proper noun, is not sufficient to use the "wrongtitle" or "lowercase" templates, or to lowercase it at the start of the article. Also the rest of the article uses uppercase at the start of a sentence. Therefore I'm restoring the capital and removing the template. --Trovatore 05:34, 30 March 2006 (UTC)

Actually, I was just heading back to the article to do a self-revert on that change, so I have no problem with that. You're right, it shouldn't use {{wrongtitle}} (or even {{lowercase}}). CRGreathouse 20:45, 24 May 2006 (UTC)

It seems wrong to me either way; wrong to change the case of a proper noun (even a lowercase one) and wrong to start a sentence with a lowercase letter. I suggest that in addition to not using the templates, we also move the word away from the start of the sentence (at least, at the very start of the article) in order to defuse the issue a bit. DanielCristofani 09:00, 26 May 2006 (UTC)

Agree. Avoiding the the issue entirely seems to be the best way of dealing with it without pissing anyone off. 219.73.21.220 (talk) 04:36, 20 July 2008 (UTC)

For future reference, here are the five uses of the word in the classic distribution. DanielCristofani 09:10, 26 May 2006 (UTC)

The brainfuck compiler knows the following instructions:

The compiler for the 'brainfuck' language (240 bytes!)

The interpreter for the 'brainfuck' language

Some example programs in 'brainfuck'

The language 'brainfuck' knows the following commands:

There are both grammar violations and non-violations, but even if I were paid I'd have hard time figuring out which should be capitalized, so I'm just leaving it as is, better for my brain although not better for anyone. ----rautamiekka (talk) 20:43, 10 November 2016 (UTC)

mistake

Would a mistake in here be called a "fuck-up"? Ethelhael (talk) 02:02, 11 August 2011 (UTC) why do I get the feeling that this article is trying very hard not to laugh out loud?

Can you please take out Bf and use something as a useful langauges. Mitchal holloway — Preceding unsigned comment added by 70.190.66.28 (talk) 16:54, 27 November 2012 (UTC)

Discussion on merging Brainfuck++

Probably thirty people have made brainfuck variants with one implementation and one to three tiny example programs. Most of these seem to be in the nature of self-assigned first exercises in language design. As such, they serve a purpose, but if we include their specifications on this page it will sink under the weight. I think listing them, with links, was a fair compromise. Any that cannot stand as independent articles should probably not be detailed in Wikipedia, since there may not be enough editors to keep them accurate.

(For the same reason, I think I'll remove the feckfeck spec from this page.)DanielCristofani 21:18, 27 August 2006 (UTC)

Better Addition Program?

I'm new to Brainfuck, but I wrote a program that accomplishes the same thing as the example. It is both shorter and takes less calculations. Here is is:

,>++++++[<-------->-],<[>+<-]>.

--Spikeman 12:08, 10 November 2006 (UTC)

I wrote a shorter and add-direct addition program. Dunno if that is still an addition program. ,>,[-<+>]<. — Preceding unsigned comment added by 61.172.12.55 (talk) 11:17, 10 July 2018 (UTC)

Strange Moving the pointer

Why isn't it

,[.>,]

? I think the first ">" in the article should not be there.

That would leave no way to get back to the start of the input. DanielCristofani 01:14, 1 December 2006 (UTC)

Pascal/Delphi Implementation

I reverted edits by [[User:158.195.101.120|158.195.101.120] and Rjwilmsi that added "Pascal/Delphi Implementation" section. The article is language-agnostic at the moment, Delphi implementation has no notability whatsoever (especially if compared to a canonical C implementation that is not mentioned here either). The reverted edit also bloated the article significantly. Alex Pankratov 17:19, 22 February 2007 (UTC)

removing Pascal Delphi implementation

hey why did you removed the pascal/delphi implem. ? its great when you try to understand how it works, so you dont need to read tons of text, its just understandable from the algorithm, yes, its taking some space (about 25 lines), but its helping much, like you understand frmo it that 256 -> 0 (when i was writing it, it took me a bit longer to get that fact, cause nowhere was smt. like that algoritm (i had to crub from a lot of long junk code l i found it), also you understand whats the condition of the loop (before i was not sure if its when ord(a[p])=0 or a[p]=0 or what ever)) delphi is an easy understandable language also for nocoder, and i think the implementation is a good addision to the text, cause on it you can understand fast and easy whats all about... and in school when we had to understand brainfuck (its learned on one hour lesson!) this help much, not only for me, but also for many of my schoolmates —The preceding unsigned comment was added by Nonename (talk • contribs) 16:52, 25 February 2007 (UTC).

In short - I reverted your edit, because it was not of an encyclopedic quality. This is not as bad as it sounds :) I agree that the information you added is helpful to people starting with the Brainf*ck and who are familiar with Pascal. Wikipedia however is not meant to be a textbook. Also, other people might prefer other languages (say, Java, Erlang or Petrovich), so assuming that Delphi would work for everyone is not right thing to do. This is what I meant that by "language-agnostic" comment above. I appreciate your contribution and I completely understand where you are coming from (as I am sure do all other editors of this page). I also hope you can also understand my rationale and this revert won't discourage you from further contributions. Not to see you effort go into a void, I would suggest creating a web page on an external to Wikipedia server and then linking to it from "External links" section. Alex Pankratov 19:57, 25 February 2007 (UTC)

The interpreter doesn't work correctly. You have forgotten this "[ jump forward to the command after the corresponding ] if the byte at the pointer is zero". For example this brainfuck program "++++++++++[>++++++++++<-]>>[<.>]<." prints "dd" instead of only one d. PowPit 13:51, 28 February 2007 (UTC)

External Links

I've removed basically the entire list of external links and links to implemtations. It was extremely out of control. What I've done is replaced it with two links. One to the Brainfuck article on the EsoLang (Esoteric Languages) wiki and other to Brainfuck/Archive 2 at Curlie. I've taken the removed text from this article and copied it onto the talk page on the Esolang page. If you feel that any of the removed links was hugely important, it might be nice to explain why before you add it back. Thanks! —mako (talk•contribs) 01:33, 18 April 2007 (UTC)

Benjamin, good move. I had been meaning to do something with them for a while - they were out of control. I think the one link to the Wiki and the DMOZ one should be able to give people all they need as far as further reading is concerned. Thanks. -- Alucard (Dr.) | Talk 02:01, 18 April 2007 (UTC)

I've just done the same with the list of variants. —mako (talk•contribs) 02:46, 18 April 2007 (UTC)

Good job! I heartily approve. --IanOsgood 03:26, 19 April 2007 (UTC)

Request to mention BrainSub in this article

I am really interested in include a reference about BrainSub in this article, and even to copy in Wikipedia (besides Esolang) the complete BrainSub article. I propose that in first paragraph, after the phrase "and is not suitable for practical use" insert "(perhaps excepting BrainSub)". What do you think?

Aacini 08:09, 7 July 2007 (UTC)

Well, I removed the list of BrainFuck compilers and tried to move them over to the EsoLangs wiki since I think that's really where they belong. It had become a completely out of control list here that was adding very little to the article. It seems much more on topic for EsoLangs. As a result (and since everything else is gone), I think it would be unfair to add a single compiler back to this article -- especially in the first or second sentence!

If you believe that BrainSub satisfies Wikipedia's notability standards, I would go create a reasonably well cited article (it can be a stub) over at BrainSub and then put in the "See also" section on the Brainfuck article. If you think it is not that notable but still warrants mention, I'd find somewhere else in the article (i.e., not the first paragraph) to mention. I'm reasonably sure that no BrainFuck compiler is so important to warrant mention in the first 25 words about the compiler.

How does that sound? —mako๛ 13:53, 7 July 2007 (UTC)

Upon looking around, I see that BrainSub was only released yesterday! It seems highly unlikely that a one-day-old esoteric programming language qualifies as notable already. —mako๛ 13:59, 7 July 2007 (UTC)

The list was removed from EsoLang shortly after it moved there (citing possible copyright problems). I think we should re-add the list back to WP, perhaps as a separate article ("BrainFuck software" or something). Alex Pankratov 15:15, 7 July 2007 (UTC)

Yes. I remember now. I believe it was license incompatibility issues which I did not notice when I made the switch. Unfortunately, I feel bad adding it back (perhaps even as a a new article) since Wikipedia is not a collection of links and that's really what that was. If you want, we could add it to my userspace somewhere (User:Benjamin Mako Hill/BrainFuck software and we can keep it there, and even work on it, until license compatibility finally happens (hopefully in the next year) and we can move it to the Esolangs wiki or we can find a place for it here or elsewhere. —mako๛ 13:16, 11 July 2007 (UTC)

I think it is hardly notable, especially if you consider a wealth of other BF compilers and interpreters of all flavours and kinds. Alex Pankratov 15:13, 7 July 2007 (UTC)

I read Wikipedia's "No original research" police and I can see your viewpoint. This police do not allows a new development be included here because "can be quite difficult to know if a new research's claims are true or not", so consult to experts would be needed. In the case of brainfuck the experts are, even more than the users that write programs in it, the people that had created a brainfuck compiler or interpreter, but that people are here! Esolang´s brainfuck entry lists more than 12 brainfuck compilers of people that had published their work in this page in first place.

BrainSub is ENTIRELY DIFFERENT to any other brainfuck compiler. The executable file is more than 10,000 bytes size, the source program is written in assembly language and contain about 6300 lines of code. The 30 KB article about BrainSub in Esolang briefly describe its more important features, but a detailed explanation of all of them is in the 170 KB BrainSub user's manual. I would like to mention just one point about BrainSub: Esolang article on brainfuck said "Many people at various times have tried to extend brainfuck to make it easier to program in"; in my opinion BrainSub is the first compiler to fully implement this goal with total success because not only allows an advanced and easy use of brainfuck in an elegant and modern way, but even could remove the "esoteric" label from brainfuck and make it the choice language to develop quick and small, one-time used programs. Anyway I think I am talking too much about this matter...

I would be really happy if a single, small mention about BrainSub could be inserted here in any place.

Aacini 01:50, 10 July 2007 (UTC)

There may be a 30KB long article in the EsoLangs wiki but you are the only person who has edited contributed to it! In fact, you seem to be the only cheerleader I can find for this BrainSub at all.

I appreciate your enthusiasm and hope are able to successfully advocate for the compiler/language. That said, Wikipedia is an encyclopedia and should report on what is already the best practices and common knowledge and can not be a soapbox for your language or cause -- no matter how deserving it may be. Perhaps, if BrainSub succeeds in the ways you feel it deserves to, we will be justified in creating a whole article for it here and linking prominently to it from this articles in others. I hope that happens, for your sake, but it's just not he case now and it can't be Wikipedia's job to help bring that situation about. —mako๛ 13:13, 11 July 2007 (UTC)

AFD: Antonio Perez Ayala

There is ongoing discussion about the deletion of the newly created Antonio Perez Ayala. The creator has argued that he is notable at least in part due to his BrainFuck compiler. Please participate and let your voice be heard if you have an opinion at Wikipedia:Articles for deletion/Antonio Perez Ayala. Thanks. —mako๛ 18:43, 12 July 2007 (UTC)

Brainfuck generator?

Is there a website out there that will translate pieces of text into Brainfuck? (As there are already text-to-binary/hex/l33t generators out there) (and Googling finds nothing)
_~~NaN 19:00, 18 September 2007 (UTC)

BF is a programming language, what exactly do you mean by a conversion from a natural language to it ? Alex Pankratov 19:28, 18 September 2007 (UTC)

Probably this person means a website that will translate text into a brainfuck program that prints that text. 130.94.161.238 11:50, 13 October 2007 (UTC)

The bot EgoBot in the IRC channel irc://irc.freenode.net/esoteric does this, and it's open source, so you might be able to adapt the source code from that. I'm unaware of an http:// website that does this, though. --ais523 10:56, 4 December 2007 (UTC)

"Implementation details"?

A user with IP address 24.87.161.50 said: "30000+ ? left-most position ? -- these are implementation details irrelevant to the _language design_"

This isn't exactly true. The waters are muddy here because brainfuck was implemented but never formally specified. But imagine being a brainfuck programmer with no idea where the pointer was, or how many cells you had to work with. It would be like being a C programmer with no idea how many bits a long int can hold. When C was specified, programmers were given numerical guarantees about things like recursion depth and number of significant characters in identifiers, as well as minimum capacities of different variable types. These are features of the language itself, and they are normative for all implementations. Although brainfuck does not have an ANSI specification, I would argue that the same is true of the 29999 cells right of the pointer.

(Note that the original documentation specifies the 30000 and the leftmost position under the heading "THE LANGUAGE", not under "THE COMPILER" or "THE INTERPRETER". That section does not specify that cells are bytes, incidentally; that is noted above and treated as an implementation detail.)

DanielCristofani (talk) 09:57, 17 April 2008 (UTC)

Well, it is an implementation guideline nonetheless, so it needs to be marked as such. You would probably agree that an interpreter that uses 1024 cells and positions the cursor in the middle is still a valid brainfuck implementation; though it may have issues running some of the programs. 24.87.161.50 (talk) 19:15, 21 April 2008 (UTC)

I would hesitate to call that a "valid brainfuck implementation". I would call it a "flawed brainfuck implementation". I would still call it a brainfuck implementation because it is trying to implement basically the same language. DanielCristofani (talk) 09:19, 5 October 2008 (UTC)

Wrapping Cells and Size of Array

In many places I have seen equivalences of brainfuck commands with C or even with BASIC or other languages, but there is an aspect is not enough mentioned. Everybody knows that the core idea of brainfuck design is "to create a compiler of the smallest possible size" but this implies, of course, that the compiled code results of the smallest possible size also. This feature leads to a basic brainfuck principle: each brainfuck command must be executed via the smallest code. The execution of a compiled brainfuck program is linked to the underlying CPU in first place, not to the programming language used to write the compiler. For example, the equivalent instructions of the first four brainfuck commands in Intel CPU's could be these: > INC DI, < DEC DI, + INC [DI] and - DEC [DI]. There is a very important aspect of these instructions that is valid also in any other CPU: if a cell/register contains zero and is decremented, the result is the maximum number that fits in that cell (255 for byte) and vice versa. From my viewpoint, this should be an intrinsic feature of any brainfuck compiled program. Note that if a brainfuck COMPILED program don't behave this way is because additional code explicitly inserted to do that; of course, this additional code should not be in "the smallest possible compiler".

Another thought is about the size of the BF array. If the CPU index/pointer register used to access the memory have 16 bits, then it can address up to 64K bytes of data and any amount below this number do not reduce the size of the compiler in any way. On the other hand, if the BF array is shorter than 64K bytes then it can lead to runtime errors if the pointer points to an out of bounds address, or require to include additional code to avoid this situation. For these reasons I suggest that the "natural" size of brainfuck array with 16 bits pointer registers be 64K bytes.

If someone write a BF compiler in any programming language other than assembler he/she should take care that the compiled code behaves the same way than the behavior of the underlying CPU. Aacini (talk) 03:41, 23 April 2008 (UTC)

Hello World!??

Currently the program doesn't print "Hello World!" but "you're a cunt" (I don't know what means that). I've changed the code to the one that is in the spanish Wikipedia.

I *almost* feel it should be left as it was, to illustrate the obscurity and un-readable-ness of the language! To whoever posted the original code, I salute you (but am also glad someone caught you out)! 146.255.183.85 (talk) 21:05, 14 December 2014 (UTC)

More Complex Examples

Until yesterday I believed brainfuck just couldn't do anything that could be considered useful, and I think most people still live in that delusion. The example that made me see this fact is Linus Åkerssons Game of Life, http://www.linusakesson.net/programming/brainfuck/index.php , which in my opinion would make a great example of more complex program. If just someone agrees with me and asks for Åkersson for the rights. Shiona 09:33, 21 September 2008, (GMT)

"sufficient" v "an unlimited"

Let me explain why I consider "sufficient" rather than "an unlimited" to be the appropriate term in "Nonetheless, like any Turing-complete language, brainfuck is theoretically capable of computing any computable function or simulating any other computational model, if given an unlimited memory store". The point of the sentence is to show that Brainfuck's computational abilities are comparable with those of other languages. While this is true, it is not designed to optimise memory use, so it is appropriate to mention (or imply) that an amount of memory that may suffice a given task in more optimally written languages may be insufficient for Brainfuck. The case of an ever-lasting task such as calculating pi to an infinite degree that DanielCristofani cites in this edit summary is trivial because any ever-lasting task would require infinite memory, infinite time and infinite power regardless of which language is used to perform the task. To imply that there is an achievable task (one that can be used as a benchmark to compare Brainfuck with other languages) which would require Brainfuck to be supplied with an unlimited amount of memory appears to be an unsupportable proposition. -- Timberframe (talk) 10:11, 6 November 2008 (UTC)

Turing-completeness should have no implications on running time nor on memory usage (as long as both are finite). It's simply used as a way to decide whether it's possible to do something. We shouldn't have to mention anything about memory or runtime.

"Sufficient" may be good enough for "computable", but for Turing-completeness, it really needs unlimited memory, or at least infinitely-extendable-as-needed memory. --Raijinili (talk) 13:07, 6 November 2008 (UTC)

I see what you mean, but again I disagree with your "infinitely-extendable-as-needed memory" concept which contradicts your first sentence where you acknowledge the finite nature of both time and memory. Enderton is quoted in these terms: "Although the procedure may use only a finite amount of storage space during a successful computation, there is no bound on the amount of space that is used. It is assumed that additional storage space can be given to the procedure whenever the procedure asks for it" - this is not infinitely extendible because that get's you back to my point that you would then need an infinite amount of time to fill the memory and so the task would never complete. The problem, I think, is that "unlimited" can be interpreted as "finite but without a specific limit" - which is what's required for Turing-completeness - or as "infinite". What "unlimited" is trying to convey in this context is not an infinite memory but a memory whose size is not limited to any specific size, in other words its only constraint is that it is "sufficient". -- User:Timberframe

First of all, I noticed that you made this edit twice. The rule is "Edit, revert, discuss", not "Edit, revert, revert, discuss". You shouldn't revert again without discussion FIRST, since this kind of behavior leads to edit wars.

As for contradiction, there is nothing that says that the Turing machine has to write to an infinite number of cells. Memory usage might be finite for computable functions, but giving the machine an infinite memory space gives the same theory as the "extendable as needed" Turing machine. In other words, we can have "unlimited" without any problem.

On the other hand, "sufficient" memory for the Turing machine to run (no guarantees about halting) can be infinite, which you clearly object to. Since there's no loss of information due to ambiguity, "unlimited" is better.

I think part of the problem is that you only want computable functions to run, which isn't enough. To allow all computable functions to run (that is, to have a machine powerful enough to compute all computable functions), you also need to be able to have non-computable functions run, and in particular the halting problem has to be in there. So you have to allow for the case of infinite (non-halting) runs, and thus infinite memory. There's no computable function that tells you how much memory a program would need, so you need to have the memory be extendably an infinite number of times. --Raijinili (talk) 05:04, 7 November 2008 (UTC)

Raijinili, my apologies, I've reverted my reversion. This is a minor esoteric point in the big scheme of things and I'm far more interested in the discussion than in starting an edit war. I understand your line of reasoning, and agree that in terms of Turing we must allow the possibility of a never-ending computation. But my point is this: neither the article nor the sentence in question sets out to explain all the provisions of Turing and it seems strange to mention this particular proviso in this context. Rather, the sentence is about the comparability of Bf to other computational models in a Turing context. Applying you arguments all models require infinite memory in order to meet this particular Turing requirement, so including the point tells us nothing about Bf while suggesting, to the reader who is unfamiliar with Turing's finer points, some deficiency in Bf compared to other models. Furthermore an unsuccessful computation has little practical value beyond showing the the the task is impossible, nor is infinite memory actually possible, so this particular requirement has no practical relevance to the article. Perhaps it would be better to drop the "if given an unlimited memory store" clause altogether. -- Timberframe (talk) 10:33, 7 November 2008 (UTC)

Several things need clearing up here. You said:

The case of an ever-lasting task such as calculating pi to an infinite degree that DanielCristofani cites in this edit summary is trivial because any ever-lasting task would require infinite memory, infinite time and infinite power regardless of which language is used to perform the task. To imply that there is an achievable task (one that can be used as a benchmark to compare Brainfuck with other languages) which would require Brainfuck to be supplied with an unlimited amount of memory appears to be an unsupportable proposition.

To compute an infinite number of digits of pi is an impossible task; but to compute digits, and go on computing more digits indefinitely until the program is stopped or the computer breaks down, is entirely possible. In fact, this is arguably more useful than computing a pre-specified number of digits; you can start the program and leave it running until you need the computing power for something else, rather than (say) picking a number you think is generous, and then deciding after a week that you want more and having to start from scratch.

(Incidentally, Turing originally conceived Turing machines as doing exactly this--computing real numbers to arbitrary precision and never terminating on their own. He calls these "circle-free machines".)

Programs of this kind will only need a finite amount of memory prior to any given time...you just have to be ready to give them more when they run out. And this isn't that odd--periodically upgrading storage capacity has been a reality of computing for decades anyway.

Personally I've written at least five brainfuck programs of this kind--they output nonterminating number sequences so I made them nonterminating programs. Each of them requires a finite amount of memory at any given time, but each will also exceed any given finite amount of memory in a finite amount of time. Although in the case of thuemorse.b, the time to exceed 1k is longer than the expected lifetime of the physical universe.

The main point being, this is a useful and achievable kind of computational task, and simulating it is required for Turing-completeness. Saying that any task can be done if you give the program "sufficient" memory strongly connotes that you can give the program as much memory as it will need, then sit back and let it do the task without giving it any more memory. And I grant that the current phrase "unlimited memory store" also sounds like a single (magic) thing that's given at the outset. I'll rephrase the article to "given access to an unlimited amount of memory". We need to leave some version of that in because 1. it's necessary to make the sentence actually true, and 2. the matter of Turing-completeness is a theoretical concept anyway. The sentence even has the word "theoretically" in it. If you're worried about hinting to people unfamiliar with the theory of Turing-completeness that brainfuck might be inferior to other languages in practical terms...well, it is. DanielCristofani (talk) 14:55, 10 November 2008 (UTC)

Perhaps it would be better to drop the "if given an unlimited memory store" clause altogether.

But to be strictly correct, you need to state the "if given unlimited memory".

As for everything else, I don't see how leaving the "unlimited memory" would confuse readers any more, and if they knew enough about Turing-completeness, they probably would be more confused by the lack of the common condition of "if given as much memory as the would require at any point in time".

It's not really a deficiency compared to other models. It's a deficiency (if you want to call it that) with all programming languages which are Turing complete. So removing it would be ignoring that deficiency. --Raijinili (talk) 04:35, 12 November 2008 (UTC)

Some notes.

I've just fixed up the references, which had been broken into two incompatible formats, and have reverted a change to the opening paragraph. The person making that change had said: "(Misleading to say that a Turing machine is not suitable for practical use)"

Several things need saying about that, to maybe stave off similar confusions in future.

One, brainfuck is not a Turing machine. Almost the only thing the two have in common, other than being tremendously minimalistic and Turing-complete, is their approximate memory model: an unlimited sequence of finite-range elements with no addressing scheme or random-access capacity, only a movable indicator that can step forward and back along the sequence, and allows access to the element it indicates at a given time. A Turing machine is, conceptually, a physical computer itself; brainfuck is a programming language for modern digital computers. A Turing machine's tape's squares can hold an arbitrary finite set of symbols, without any specific ordering; brainfuck array cells hold integers, often bytes. A Turing machine's program is not written sequentially, but specifies transitions from one combination of numbered-global-state and current tape symbol to the next state and symbol; a brainfuck program is a sequence of commands which are performed in the order they are written in, without looking at the tape, except for loops. A brainfuck program does output, and maybe input; a Turing machine does not, but leaves its "output" on its tape.

Two, "Turing machine" does not mean "Turing-complete computer". I've seen the two confused with each other. Probably this is because Turing did work on real computers in the 40s, after having devised Turing machines as a thought experiment about the limits of computation, in his 1936 paper.

Three, a Turing machine is in fact not suitable for practical use. They are too slow: the lack of random-access memory, and the lack of specialized circuitry to quickly do common tasks like addition, are obvious, absolutely debilitating limitations; even in the 1940s they built better computers than that. The only Turing machines ever built were built much later by hobbyists unconcerned with practicality.

Four, brainfuck is not suitable for practical use. The things it shares with Turing machines--its minimalism and its lack of random-access memory--are just as debilitating to brainfuck as they are to Turing machines.

DanielCristofani (talk) 19:36, 25 November 2008 (UTC)

I don't agree with much of this, or at least I think most of it is needless pedantry. But in the specific case of "practical", you are confusing "practical" with "competitive". Wind back to the days of Babbage and the navies of the world would have paid good money for a brainfuck interpreter that could grind out log tables even if it took six months. The language, and a Turing machine, is capable of practical use, it's just that there are now better alternatives.128.86.248.115 (talk) 11:53, 12 March 2014 (UTC)

Granted, nobody really needs the language, let alone a Wikipedia article about the language, so trying to clarify matters of linguistic usage in the talk page of that article is frivolous. All the same, I think common usage would favor saying that what is practical depends on what options are available. Neither brainfuck nor Turing machines have ever been a practical choice since they came into existence, and they aren't now. They would have been practical if they had been available a century earlier (and other computing technologies were not); that doesn't mean that they are. DanielCristofani (talk) 15:04, 4 February 2015 (UTC)

Tone issues

I'm tagging the "examples" section with {{tone}}; the use of first person pronouns ("Here we see...") isn't appropriate per WP:TONE. I'm also concerned as to whether it's encyclopedic, in terms of WP:NOTGUIDE. —/Mendaliv/^2¢/_Δ's/ 13:21, 24 December 2008 (UTC)

Your concern seems unwarranted. This page is above average in informativeness and comprehensibility. I ask the next editor to remove the tone tag if they also see no problem with the tone. Enon (talk) 05:42, 22 January 2009 (UTC)

I took the liberty of cleaning up the objected WP:TONE violations. Someone feel free to correct anything where they feel the spirit of the original text was lost (I think I did alright, but I'm open to criticism). The tone tag has been removed in accordance with that, but if anyone (ie: Mendaliv) still objects to the WP:NOTGUIDE, which seems appropriate and justified to me, it's going to need a rather heavy rewrite. I think the entire section could stand on the grounds of demonstrating the turing completeness of the language itself, but I also think a referential citation would work just as well, and stand the test of WP:NOTGUIDE criticism far better.

Minor footnote, there are multiple areas where "input" and "output" are used as verbs. Though I'm far from an authority on the english language, I'd argue that "inputted" and "outputted" are slightly more technically correct in at least some of those cases. Anyone with an english degree, please feel free to step up to the plate and copyedit the hell out of that. - Pegasus Epsilon (talk) 06:45, 22 January 2009 (UTC)

I've thought for a long time, partly on WP:NOTGUIDE grounds, that we should scrap all the tiny example programs and have just two: "Hello World" and something bigger. I picked out a ROT13 program for the purpose. Then I started writing an explanation, and (being a perfectionist) I got stalled. That was almost four years ago. I still think it would be a better idea than what we have now though. DanielCristofani (talk) 09:03, 28 February 2009 (UTC)

-,+[
    -[
        ->+>++++[>++++++++<-]
        <<[>+>+>-[>>>]<[[>+<-]>>+>]<<<<<-]
    ]>>>[-]+>--[-[<->+++[-]]]<[
        ++++++++++++<[>-[>+>>]>[+[<+>-]>+>>]<<<<<-]
        >>[<+>-]>[-[-<<[-]>>]<<[<<->>-]>>]<<[<<+>>-]
    ]<[-]<.[-]<-,+
]

Put the excess examples in a separate article, and prepare that article for being moved to wikibooks. Just a suggestion... Rursus dixit. (^mbork³!) 13:41, 3 May 2010 (UTC)

Link [2] not working (error 404)

Link [2] not working (error 404) —Preceding unsigned comment added by 77.78.94.13 (talk) 16:12, 4 January 2010 (UTC)

Working now. Rursus dixit. (^mbork³!) 13:42, 3 May 2010 (UTC)

c++ bf-interpreter

A c++ implementation of a simple bf-interpreter, made for a just-for-fun-mini-contest. The basic idea was not only to write c++, but kind of 'think' c++. Documentation and examples are given in comments.

If you find it useful, rework the comments, (maybe) rewrite some code (but make sure it runs :D), and add it to the article. If not, ignore it.

Maybe you find some bugs, just let me know. License is public domain ofc, do what ever you want with it.

source code

#include <iostream>
#include <string>
#include <vector>
#include <stack>
#include <iomanip> //for memdump in main()

using namespace std;

/*
dynamic memory size
dynamic data type (T)

T can be any built-in or user defined datatype (struct or class), that provides the following:

1. a 0 like element and a constructor T::T(0) that returns that 0-element (used for initialization, also see 5.)
2. a prefix(!) increment operator (as int, float e.g. does not have sth like that)
3. a prefix(!) decrement operator (same…)
4. a T::T(const T&)-constructor (copy constructor) required by vector/list/…
5. a bool operator that returns false if the elements value equals T(0), true if not (used for braces)
6. a >> and << operator working on istream / ostream

*/

const unsigned msize = 10; //memory limit (in cells, not bytes)

template <class T = uint8_t, bool wraps = false> //common implementation is 8 Bit unsigned. wrap = true: memory wraps around (like bf reference implementation, but not turing complete anymore)
void bfi(const string& prg, vector<T> * const memory = 0) //prg is a string containing the brainfuck source, memory might be given by the caller if he wants the dump afterwards
{
  vector<T> * mem;
  if (!memory) mem = new vector<T>; else mem = memory; //if the caller doesn't provide memory (he dont want a memdump), we make our own
  try {
    stack<string::const_iterator> backjumps; //jump marks for loops
    if (mem->size() == 0) mem->push_back(T(0));
    typename vector<T>::iterator m = mem->begin();

    //check loop labels. the idea is simple: +1 on opening, -1 on closing, and the counter 1. must never drop below 0 (would be sth like "[]][") and 2. must be 0 after all (every "[" has its "]")
    int j = 0;
    for (string::const_iterator p = prg.begin(); p != prg.end() && j >= 0; ++p) if (*p == '[') ++j; else if (*p == ']') --j;
    if (j) throw string("[] mismatch");

    for (string::const_iterator p = prg.begin(); p != prg.end(); ++p) //execute the code
    {
      switch (*p) {
        case '+' : ++*m; break;
        case '-' : --*m; break;
        case '.' : cout<<*m; break;
        case ',' : cin >>*m; break;
        case '>' :
          ++m;
          if (mem->size() >= msize && m == mem->end()) wraps ? m = mem->begin() : throw string("memory exceeded");
          if (m == mem->end()) {mem->insert(mem->end(), T(0)); m = mem->end() - 1;} //expanding memory
          break;
        case '<' :
          if (mem->size() >= msize && m == mem->begin()) wraps ? m = mem->end() : throw string("memory exceeded");
          if (m == mem->begin()) {mem->insert(mem->begin(), T(0)); m = mem->begin();} //expanding memory. keep in mind that extending a very large vector at the beginning might be slow, but normally vector is faster than list
          else --m;
          break;
        case '[' : if (!*m) { //opening '[' found and cell is 0, now we look for the matching ']'
            int c = 0;
            do {
              if (*p == '[') ++c; else if (*p == ']') --c;
              ++p;
            } while (c);
          }
          else backjumps.push(p); break; //start a loop, just save the current jump label
        case ']':
          if (*m) p = backjumps.top(); //cell is not 0, loop
            else backjumps.pop(); //cell is 0, kick the current jump label and proceed
          break;
      } //switch
    } //for
    if (!memory) delete mem; //delete our own memory
  } catch (...) {if (!memory) delete mem; throw;} //any exception occured, cleaning up and re-throw
}

template <bool wraps> void bfi(const string& prg, vector<unsigned char> * const memory = 0) {bfi<unsigned char, wraps>(prg, memory);}

int main()
{
  try {
    // Usage:

    //only run without wrapping memory
    bfi("+[>+]");

    //another type
    bfi<unsigned int>("+[>+]");

    //both of these examples will fail quickly with "memory exceeded"

    //wrap memory at msize, using uint8_t
    bfi<true>("+[>+]");

    //same but will run ages
    bfi<unsigned long long,true>("+[>+]");

    //get a memdump
    vector<uint8_t> mem;
    bfi<true>("+[>+]", &mem);

    //preinit the memory is also possible. note: this kind of initialization is c++0x, normally you would push_back the values one by one
    mem = {1,2,3,4,5,6,7,8,9,0};
    bfi<true>("+[>+]", &mem);

    //print memdump. ofc this special snippet may not work with user defined datatypes, or even with signed (change the static_cast for that)
    for (vector<uint8_t>::const_iterator i = mem.begin(); i != mem.end(); ++i)
      cout << hex << setw(sizeof(mem[0]) * 2) << setfill('0') << uppercase << static_cast<unsigned>(*i) << " ";
    cout << endl;

  } catch (string &e) {cout << "exception: " << e << endl;}
  return 0;
}

188.102.99.205 (talk) 21:49, 7 January 2010 (UTC)

A short version in FreeBasic, while we're at it

Uses standard input and output streams, 30,000 byte memory array, and (iirc) wraps around on overflow.

source code

dim mem(30000) as ubyte
redim stack(1 to 1) as integer
dim as string code, y
dim as integer x, position, mempos
open "**FILENAME**" for input as #1
while not eof(1)
	line input #1, y
	code = code + y
wend
close 1
position = 1
while position <= len(code)
	select case mid(code, position, 1)
	case ">"
		mempos = mempos + 1
	case "<"
		mempos = mempos - 1
	case "+"
		mem(mempos) = mem(mempos) + 1
	case "-"
		mem(mempos) = mem(mempos) - 1
	case "."
		print chr(mem(mempos));
	case ","
		mem(mempos) = cubyte(getkey)
		if mem(mempos) = 13 then mem(mempos) = 10
		print chr(mem(mempos));
	case "["
		if mem(mempos) = 0 then
			x = 1
			do
				position = position + 1
				select case mid(code, position, 1)
				case "["
					x = x + 1
				case "]"
					x = x - 1
				end select
				if x = 0 then exit do
			loop
		else
			redim preserve stack(1 to ubound(stack)+1)
			stack(ubound(stack)) = position
		end if
	case "]"
		if mem(mempos) > 0 then
			position = stack(ubound(stack))
		else
			redim preserve stack(1 to ubound(stack)-1)
		end if
	end select
	position = position + 1
wend

— Preceding unsigned comment added by 68.32.37.109 (talk • contribs) 01:25, 28 February 2010

An even shorter C++ version of it()

Only has 23 lines!!

#include <bits/stdc++.h>
int main() {
    char code_pointer = 0, p = 0, m[300000], c[300000] = ",[.-[-->++<]>+]";
    std :: stack <int> b; std :: map <int, int> a;
    for(int i = 0; c[i] != 0; i ++) {
        if(c[i] == '[') b.push(i);
        else if(c[i] == ']') {
            int n = b.top();
            b.pop();
            a[i] = n; a[n] = i;
        }
    }
    for(; c[code_pointer] != 0; code_pointer ++){
        if(c[code_pointer] == '>') ++ p;
        else if(c[code_pointer] == '<') -- p;
        else if(c[code_pointer] == '+') ++ m[p];
        else if(c[code_pointer] == '-') -- m[p];
        else if(c[code_pointer] == '.') putchar(m[p]);
        else if(c[code_pointer] == ',') m[p] = getchar();
        else if(c[code_pointer] == '[') { if(m[p] == 0) code_pointer = a[code_pointer]; }
        else if(c[code_pointer] == ']') if(m[p]) code_pointer = a[code_pointer];
    }
}

Actually, to make it shorter, I deleted the "return 0;". To make it able to run",[.-[-->++<]>+]", I changes it into:

#include <bits/stdc++.h>
int main() {
    int p=0,m[300000],code_pointer=0;
	char c[300000]=",[.-[-->++<]>+]";
    std :: stack <int> b; std :: map <int, int> a;
    for(int i = 0; c[i] != 0; i ++) {
        if(c[i] == '[') b.push(i);
        else if(c[i] == ']') {
            int n = b.top();
            b.pop();
            a[i] = n; a[n] = i;
        }
    }
    for(; c[code_pointer] != 0; code_pointer ++){
        if(c[code_pointer] == '>') ++ p;
        else if(c[code_pointer] == '<') -- p;
        else if(c[code_pointer] == '+') ++ m[p];
        else if(c[code_pointer] == '-') -- m[p];
        else if(c[code_pointer] == '.') putchar(m[p]);
        else if(c[code_pointer] == ',') m[p] = getchar();
        else if(c[code_pointer] == '[') { if(m[p] == 0) code_pointer = a[code_pointer]; }
        else if(c[code_pointer] == ']') if(m[p]) code_pointer = a[code_pointer];
    }
}

Trimmed examples.

So I finally got around to adding a sizable example and removing all those bitsy examples. Not sure if the introductory explanation is clear enough. Thoughts? DanielCristofani (talk) 03:34, 8 September 2011 (UTC)

Not sure if you're the one who added the ROT13 one, but that's a great example (and a very nice program). Concise, and useful. I'm not too happy to see some of the examples of program "atoms" go. Sure, it was a bit excessive the way it was, but I'm not sure they were all useless for explaining brainfuck.

--Qwerty0 (talk) 19:41, 8 September 2011 (UTC)

Yeah, that was me. (The program is originally Bertram Felgenhauer's, with improvements by me; I got his approval to put it on here a long time ago.) I'm not saying the examples were useless, but I think we can explain the same things in the context of the two example programs I left in place, and I think that would make it look more like an encyclopedia article and less like a brainfuck tutorial, which there had been some complaints about.

(As part of learning brainfuck, people will inevitably have to think through the operation of some programs, command by command. I think the Hello World is not intrinsically too scary as a first program to trace through, though it's possible that some features of it need to be singled out more in the text description, or explained in more detail.)

The major thing that was in the examples I took out, but not included in the programs I left, was the use of variable-sized data. Perhaps we should include the reversal program >-,+[>-,+]<[-.<] as another example, after Hello World but before ROT13? And maybe that would be less intimidating as a second program to trace through. DanielCristofani (talk) 13:36, 9 September 2011 (UTC)

Censorship, Against policy

Please. Whoever is editing this article to take out the "uc" in Brainfuck and replacing it with "**" Stop doing so. I will explain why. Wikipedia is not censored. It's been discussed ad naseum why it is not and it is policy to not censor articles. Please See WP:CENSOR, Wikipedia:Censorship (2006 proposal), Wikipedia:Offensive material if you need further clarification. —ASPENSTI—TALK—CONTRIBUTIONS 15:37, 21 September 2012 (UTC)

exsistence of CrossCompilers

a section to translate code subsets big as possible of -imperative-? pl-s would be a idea, if it s a good one, you might know.

79.234.195.217 (talk) 19:22, 22 October 2013 (UTC)

EOF behaviour or ROT13 example

Quote:

Leaving the cell's value unchanged is the behavior of Urban Müller's brainfuck compiler. This behavior can easily coexist with either of the others; for instance, a program that assumes EOF=0 can set the cell to 0 before each "," command, and will then work correctly on implementations that do either EOF=0 or EOF="no change". It is so easy to accommodate the "no change" behavior that any brainfuck programmer interested in portability should do so.

This means that for many interpreters the previous value of the current cell DOES have an effect for the "," command.

The form "[-]-,+[" makes the input compatible with interpreters that set the cell to "-1" on EOF and interpreters that leave the cell unchanged on EOF. Removing the "-" to make "[-],+[" breaks the code for interpreters that leave the cell unchanged on EOF. Interpreters that set the cell to zero on EOF don't work with either of these code fragments. I would be happy for you to add a change that makes the code work with all three EOF conventions.

Therfore I have reverted to [19:54, 19 March 2014‎] 2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 20:46, 21 March 2014 (UTC)

Merger proposal

Well, merging the articles sounds good to me, but only in case references can be provided for the Ook Ook article. — Dsimic (talk | contribs) 21:54, 31 March 2014 (UTC)

Ok, now we have a reference. :) — Dsimic (talk | contribs) 23:05, 31 March 2014 (UTC)

It still seems pretty far-fetched to me. You could achieve the same using any given three symbols, words or phrases. Let's invent the "wiki", "pe", "dia" programming language! Richard 07:50, 1 April 2014 (UTC)

Esolangs Wiki makes the assertion that "Ook!" is the first publicized brainfuck-derived language "in a long line of trivial Brainfuck command substitutions", which seems credible to me and would certainly warrant a mention in the brainfuck article. On the other hand, I am having trouble finding reliable sources to back that up at the moment. M. Caecilius (talk) 08:24, 1 April 2014 (UTC)

Sure thing, merger makes sense only in case we can provide reliable sources for the Ook Ook article. — Dsimic (talk | contribs) 02:52, 2 April 2014 (UTC)

Agree, even if it isn't the first it's a good example of the very widespread 'sport' of making exact duplicates of BF except for the symbols used. It may in fact be that BF itself is actually the first language to do this. It is after all suspected that Urban Müller knew of Corrado Böhm's work. The language Ook (Just one ook for the "official" name) itself isn't actually notable on it's own IMO. 2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 19:25, 7 April 2014 (UTC)

Learn Perl 1 is self-published through Lulu.com and is not a reliable source. Ook! is mentioned/discussed in a single sentence on three different pages in Poétique des codes sur le réseau informatique, which is a reliable source. There is a fifth AfD discussion on the Ook! language at Wikipedia:Articles for deletion/Ook Ook, with current consensus leaning toward merging here, based on what was described as a "rough consensus" to merge reached here. Agyle (talk) 08:14, 21 June 2014 (UTC)

In re "Interpretation as art" section

An anonymous user removed this section because, as they wrote in the edit summary, "We do not need a postmodern interpretation of every non-traditional contribution to technical fields such as computer science." With this I disagree. Perhaps the second source given in that section is somewhat iffy and less than reputed, but the publication by G. Cox cited seems after a cursory research to be well-respected in the field of New Media. Whether a "postmodern interpretation" of technical field is "needed" is not Wikipedia's call to make, nor is the evaluation of merits of fields such as New Media when their discourse happen to involve technical subjects such as programming languages. If there is any disagreement, please use this talk page to reach a consensus before re-applying the disputed edit. Thank you. M. Caecilius (talk) 23:22, 24 May 2014 (UTC)

Yes, I am said anonymous user. I did not realize that pressing "Enter" would submit my edit summary, rather than insert a newline, as I have never been compelled to edit an article before. This section had not been here the last time I visited the brainfuck page, and it was such outrageous nonsense that I figured there was no reason to go back and add a further summary of its deletion. Since I was mistaken, I will continue with my reasoning for deleting the "Interpretation as art" section, and then I will address your arguments for its persistence/reinstatement.

• • We do not need a postmodern interpretation of every non-traditional contribution to technical fields such as computer science. Wikipedia is not a postmodern or New Media critique archive; it is intended to be field-neutral, so each article should focus on the fields of relevance to the article's subject or fields to which it has some tangible, substantial connection. More importantly, the interpretations offered in this section are of extremely dubious intellectual value, and betray the quoted author's lack of understanding or even familiarity with programming languages. The statement that esoteric programming languages "somewhat undermine the interpellative authority of the computer and stress alternative interpretations like the paradoxical qualities of speech" is of dubious merit: in what way does an esoteric programming language undermine the "interpellative" authority of the computer, especially in comparison to "regular" programming languages? How do they stress "alternative interpretations"—especially given that all programming languages are eventually translated to the same kind of machine language—such as the "paradoxical qualities of speech", and what are these "paradoxical" qualities that are being stressed? The next cited author believes brainfuck challenges the way programming languages reinforce the logical and compulsive thinking inherent in communicating with computers. How so? If anything, a barebones language without syntactical nicety should only further the programmer's need to think logically, as even a non-programmer might conclude after reading the prior sections of this article. It is also unclear what "compulsive thinking" Temkin is referring to, and no clarification is given for this statement. The next statement, that "brainfuck allows irrationality to blossom in a place of exactitude, recalling systems-based work by Sol LeWitt and the event scores of Yoko Ono" is at least as problematic. Nothing about programming in brainfuck encourages irrationality, at least no more than non-esoteric programming languages. The connection between brainfuck and these professional artists, or their work, is doubtful, to say the least. brainfuck may well be a playful programming "experiment" to challenge programmers, but it is not presented by the author as any category of art, and it is not a performance piece—experimental or otherwise—so it is a wonder how brainfuck is expected to recall the work of Sol LeWitt and Yoko Ono. The final line of the section, "where programming languages are denotative, the bodily gesture and nuance that comes naturally to humans communicating comes in through esolangs," is not merely meaningless, it is idiotic. With all of the above in mind, I cannot see any reason to defile an otherwise informative and on-topic article with completely meaningless drivel.
  • As to your arguments, I'd first like to address this: "'We do not need a postmodern interpretation of every non-traditional contribution to technical fields such as computer science.' With this I disagree." That is quite the disagreement. Should we have an "Interpretation as art" section for the pages of math theorems? How about articles on chemical synthesis methods? Mammal species? Setting aside the quality of this particular "Interpretation as art" section, each article should pertain to the subject at hand and the fields that are tangibly related to it; Wikipedia is not a space devoted to practicing one's postmodern discourse skills. There are places for that, and the article for a programming language is not one of them. You mention the credibility of the sources cited, which I did not, but it's worth discussing. The book cited is predictably obscure; it has no reviews on Amazon nor on goodreads. Of what I could find on the rest of the web, it has two agreeable reviews put forth by students in liberal arts fields, one lukewarm and slightly negative review from an MIT student programmer, and one scathing review by a professional software developer. (Ironically, the homepage of this dev's company, of which he is Chief Scientist, mentions New Media.) It does not seem to have been well received—when read at all—by anyone knowledgeable of computer science. Cox's reputation in New Media is unknown to me, and frankly irrelevant, as brainfuck is not particularly related to his field. He may try to argue otherwise in his book, but the quoted material is unconvincing. The other source, authored by Temkin, is apparently, to borrow a phrase from a field actually related to brainfuck, vaporware. I cannot find a single instance of it being cited by another scholar, though this entire "Interpretation as art" section comes up verbatim on quotesome and nyanglish, leading me to suspect that the author of the section may be Temkin himself. This is further supported by the fact that a glance at Temkin's other work available on the net shows that he is trying to make some sort of academic career out of arguments of esoteric programming languages as New Media art, with brainfuck mentioned often. His arguments could only be convincing to non-programmers. In response to your statement of "whether a 'postmodern interpretation' of technical field is 'needed' is not Wikipedia's call to make, nor is the evaluation of merits of fields such as New Media when their discourse happen to involve technical subjects such as programming languages," I will have you note that I did not make any critique of postmodernism or New Media in my original edit summary, nor in this clarification. The issue at hand is relevance and informativeness of the section. It is not relevant, and the statements cited from non-experts to the subject (that being brainfuck) are of dubious credibility. Though I will concede that Temkin appears to be some form of amateur programmer, this does not make his statements any more informative, and his interviews make it clear that New Media (a term I had not heard prior to reading his essays) is his field of interest and prospective employ, not programming.

Since I see no argument for retaining the section other than that it is appropriate to have an "Interpretation as art" section for every page (it isn't), I consider this matter closed. I expect the section to remain absent unless a more compelling argument is put forth regarding the relevance of an "Interpretation as art" section in a programming language page (esoteric or otherwise). There is also the question of quality and informativeness of the content of this "Interpretation as art" section, for which I see only one possible answer. Here is the source of the scathing review for Cox's book, if anyone is interested:

http://www.markbernstein.org/BooksSpring2012/SpeakingCodecodingasaesthe.html

-- anonymous supervillain 108.203.162.123 (talk) 22:25, 25 May 2014 (UTC)

I don't object to anything you said per se, but they are substantial evaluations of Mr. Cox's book's merits and not reasons for removing his views from the article. Much of what you said is honestly original research, but if you wish to include in the section Mr. Bernstein's critique, you would be exceedingly welcome to in a neutral manner, such as "Cox's arguments have been refuted by professional programmers such as Mark Bernstein, who argued...", etc. Removing the whole section at once because of "lack of credibility", however, is not warranted.

While you may disagree with Cox, there is no question that his book is reputable (having been published by the MIT Press), at least from a New Media standpoint. I understand that you may not have known this, but there is quite simply no guideline that states that articles about a technical subject cannot incorporate reputable sources that deal with non-technical aspects of the subject. You ask me if we should contain philosophical interpretations of "math theorems" or "chemical synthesis methods". The short answer is, if someone well known (not necessarily in the field of mathematics or chemistry, but in philosophy or other liberal arts fields) writes a book about it and publishes it through a reputable channel, then yes, we can include it in the article. To do otherwise would be to practice censorship because of your personal opinion on philosophical analysis of technical fields.

Of the top of my head, I'll give you one example. Skolem's paradox is a mathematical concept with a philosophical paper written by Hilary Putnam arguing a philosophical implication which was more recently dismissed by Wilfred Hodges as incongruous with the full Löwenheim–Skolem Theorem. Does this mean that Mr. Putnam's famous paper should not receive a mention in that article? Certainly it should. Wikipedia is not here to evaluate arguments. If it comes from reputable sources (and not crackpot blog posts), then we can include it. If there is disagreement, we report on the disagreement and the consensus in a neutral way, not removing the material disagreed with.

Finally, I should remind you that before a consensus is reached you should absolutely not repeatedly apply the disputed changes, as this goes against the spirit of conflict resolution. Re-applying the changes before a consensus is reached may very possibly lead to edit restrictions and temporary blocks, should you persist in this behaviour. Thank you for the understanding. M. Caecilius (talk) 01:54, 26 May 2014 (UTC)

It is imperative that you address the entirety of my argument for the removal of this section, not just my cursory evaluation of the reputation of Cox's book. I must remind you that I only mentioned the potential merit of his book in response to your argument that the section should be kept because Cox's book seems "to be well-respected in the field of New Media". Were that true—which is doubtful, as no evidence has been provided to support this claim—it would still be a side-point, as my original argument (the first bullet point of my first response) does not address Cox's authority nor his renown, or lack thereof, in the field of New Media. Instead, I have focused on the content of the statements made by both sources cited in the section, not their credentials. You should note that your statement that I have quoted above is an example of Argument from authority, and it does not ultimately and incontestably uphold the inclusion of content in an article. Instead, we must evaluate its notability and point of view, among other things.

As to whether "lack of credibility" is sufficient reason to remove content, I believe that it is, and I find it rather disconcerting that any editor would take a conflicting stance. Should we retain all content that fails to demonstrate any ounce of credibility (regardless of the reputation of the author)? I would very much like you to address this question in your response to this revision to the talk page, should you make one. As far as the option to include Bernstein's criticism, I am not lobbying for the inclusion of an alternate viewpoint, I am questioning the notability of the content, as well as its scholarly rigor, and thus the rationale for its inclusion in this article. We are not here merely to correct spelling and grammar errors, as someone must decide to add content, and the notability and credibility of added content is to be debated among us, the editors. This is called Editing, not "original research". In particular, you may want to review the concept of Technical editing. Perhaps I have misunderstood your statement, when in actuality you are arguing that I personally cannot assess the credibility of either Dr. Geoff or Daniel Temkin. If that is because we are merely editors, you must realize that Wikipedia cannot hope to provide much more than misinformation if it does not rely on editors with expertise of topics covered, much as well-sourced essays written by students in secondary education will generally be less educational than those of graduate students. If there are no such editors, articles will be plump with well-sourced misinformation, so it is crucial that there be editors who can judge credibility, relevance, and notability of content added through their expertise of the subjects at hand. If instead this is an attack on me rather than the crucial role of editors in general, I will have you know that it takes a meager modicum of computer science schooling to grasp what little is actually meaningful in the "Interpretation as art" section, and that my knowledge comfortably surpasses that amount. And to preempt one of your potential counterarguments, I will also note that there is nothing in that section that requires special knowledge of New Media or any other discipline to be "properly" understood. It is written as a postmodern critique, but there are no degrees granted in that "field", nor is anyone a recognized expert, though I am quite comfortable claiming as much expertise as there is to be had in "pomo critique".

In response to your statement that "I understand that you may not have known this, but there is quite simply no guideline that states that articles about a technical subject cannot incorporate reputable sources that deal with non-technical aspects of the subject," I will ask that you refrain from questioning whether I harbor bizarre delusions about Wikipedia guidelines, as I did not make any statements that should lead you to question my beliefs on the subject. On the contrary, I claimed that "we do not need a postmodern interpretation of every non-traditional contribution to technical fields." I would like you to carefully note the word "every" in that quote: this is a matter of notability. In particular, please review the section on verifiable evidence, and note the following quote: "No subject is automatically or inherently notable merely because it exists: The evidence must show the topic has gained significant independent coverage or recognition, and that this was not a mere short-term interest, nor a result of promotional activity or indiscriminate publicity, nor is the topic unsuitable for any other reason." My above quote is consistent with Wikipedia's guidelines concerning neutral point of view; namely, that fringe and insignificant minority opinions are not to be included in articles in the interest of due weight. We will come back to discuss Wikipedia's notability guidelines when we address the issue of this section's original creation by a fellow anonymous user.

You have stated that "You ask me if we should contain philosophical interpretations of 'math theorems' or 'chemical synthesis methods'", and it is crucial that you acknowledge that I did no such thing. I asked you if "we [should] have an 'Interpretation as art' section for the pages of math theorems? How about articles on chemical synthesis methods? Mammal species?" Thus, you have generalized my completely unambiguous questions into something semantically different (conveniently neglecting "mammal species" in this revision), to which you can say "yes" to. This is an example of straw man tactics, and it is calling into question whether your intentions are to come to a consensus about the notability of a section in the brainfuck article or to "win" this argument. I would very much like to stay on topic, so please address my specific arguments rather than dismissing them as "original research" or reinterpreting them in order to exploit straw man tactics.

I will address the question you erroneously attributed to me because it furthers an important discussion and gives me an opportunity to respond to your arguments. You respond to your own question with "The short answer is, if someone well known (not necessarily in the field of mathematics or chemistry, but in philosophy or other liberal arts fields) writes a book about it and publishes it through a reputable channel, then yes, we can include it in the article. To do otherwise would be to practice censorship because of your personal opinion on philosophical analysis of technical fields." Firstly, just because we can include something in an article, does not mean that we should. It must be notable and its inclusion must not constitute undue weight. Secondly, the notion that if someone is "well known" and published through a "reputable channel" we allow them to analyze topics in other fields and confer onto them all the credibility they receive when discussing their own field of expertise is simply absurd. Yes, they may be an expert in philosophy or New Media, but they have no more authority than a layman when analyzing topics outside of their expertise. No amount of expertise in one field gives them credibility when analyzing topics in a field whose first principles they are ignorant of. To dismiss an argument because the author is completely ignorant of the topic or the field it belongs to is not "censorship", it is critical thinking. I certainly hope this is not a contentious claim. Finally, you have once again propped up a straw man (or perhaps it is just a gross misunderstanding) when stating "To do otherwise would be to practice censorship because of your personal opinion on philosophical analysis of technical fields". Please do not presume to know my opinion on the philosophical analysis of technical fields (a very broad topic). The issue at hand is whether this particular analysis has any merit or is anything more than a small minority (or even single-person) opinion. All technical fields have philosophical underpinnings that are value-laden. Philosophical analysis is not only acceptable, it is essential to a deeper understanding of the field in question. There is a reason we call the most knowledgeable experts in all fields, technical or otherwise, doctors of philosophy. The viewpoints in question are simply bunk, unsupported, and single-person (Geoff and Temkin make separate claims that have no meaningful connection to each other).

In response to your example of the inclusion of content relating to the philosophical implications of a mathematical concept, I will provide you with a counterexample that more appropriately addresses the issues at hand. Luce Irigaray is a well-known, respected, and reputable feminist philosopher and linguist. She has PhD's in both fields and has authored a large number of books. On the other hand, she hold's no degrees in physics. Despite this, she analyzes both the mass-energy equivalence equation (aka E=mc²) and the field of fluid mechanics, stating "Is E=Mc² a sexed equation? Perhaps it is. Let us make the hypothesis that it is insofar as it privileges the speed of light over other speeds that are vitally necessary to us. What seems to me to indicate the possible sexed nature of the equation is not directly its uses by nuclear weapons, rather it is having privileged that which goes faster," and asserts that fluid mechanics is unfairly neglected because it deals with "feminine" fluids in contrast to "masculine" rigid mechanics, respectively. Both of these claims are notable enough to be included in different Wikipedia articles, however they are curiously absent from both the Mass–energy equivalence and Fluid mechanics Wikipedia pages. Does that illustrate the point more clearly? If not, I challenge you to add each of those analyses to the pages of the topics they refer to, as the arguments for doing so are identical to those for retaining the section of the brainfuck article that I have removed.

You go on the state that "Wikipedia is not here to evaluate arguments. If it comes from reputable sources (and not crackpot blog posts), then we can include it." This is not exactly true, nor could it be. In order to decide what is a "crackpot blog" and what is not, we must have editors knowledgeable of the topics covered who can evaluate the arguments and information in a given blog for validity, credibility, and notability. If this were not the case, and every argument published by any reputable source were included in each article, the articles of popular and much-debated topics would be tens of thousands of pages long with hundreds of contradicting arguments, each one given equal weight for having been supported by a reputable source. The fact that one of the sources of this section is an academic and a PhD holder does not override this, as academic debate is not ruled by nor prone to consensus. As editors, we DO evaluate the merit of sources, not just their apparent reputations, so that a reasonably concise article can be written that represents the most widely held, germane opinions, arguments, and information, omitting the rantings of minor academic cliques or individuals that get their hands on topics that knowledgeable editors can ascertain they do not understand.

Let's get back to the actual section in question. It was originally created in June of 2013 with the following comment: "added interpretation as art section to reflect the growing conversation about esolangs as art pieces". Note that no additional comment was added to the Talk page to expand on this reasoning or provide arguments in its support. Please review the What Wikipedia is not page and confirm that Wikipedia is not a discussion forum, and thus it is unclear as to why a section has been added to the brainfuck page "to reflect growing conversation". This also touches on why it would be inappropriate to quote Bernstein in order to refute the content of this section: the Discussion Forum bullet point specifically states that "You can chat with people about Wikipedia-related topics on their user talk pages, and should resolve problems with articles on the relevant talk pages, but please do not take discussion into articles." Also, please reread the section in question. I could not use Bernstein to "refute" any of the claims made in the section, as they are as they are primarily postmodern critiques that cannot be rigorously disproven. Instead, the section makes dubious claims that are ill-supported when at all relevant to the rest of the article and have extremely vague, unclear semantics with a sociological cant that is at odds with the remaining content of the article. The entire section reads as a postmodern critique even though only one of the five sentences is a direct quote. It reads with exactly the same tone as Temkin's essay that is cited as a source. In fact, Temkin quotes Cox in the cited essay, providing further evidence that the section was made as an act of self-promotion by Temkin and adding another item to the list of notability problems. I think it is pertinent to reflect on the reasons why Luce Irigaray's criticisms are not included in the pages of the technical topics that she analyzes, and see that those same reasons apply to this case. It may be that the section is better suited to its own page, as the topic, content, and tone of the section bear little connection to brainfuck and are of questionable educational value to anyone who finds the rest of the brainfuck article informative. Also note that the quote by the more reputable of the two sources refers to esoteric programming languages in general, not to brainfuck, calling into question its inclusion in this already source-poor section. Similarly, the original creation of the page mentions esoteric programming languages as art, however this section was created in the brainfuck page, not the Esoteric programming language page, and the cited material does not specify or even hint at what features of brainfuck lend itself to interpretation as art in comparison to other programming languages, esoteric or not. More damning is the fact that, despite this section being created a year ago, the only additional information added about this "growing discussion" during this time was a slight expansion of the quote by Temkin. (Performed by another anonymous user, probably also Temkin.) And it is Temkin that is the problem, as he appears to be the only person engaging in this "conversation" about esoteric programming languages as art. This egregiously violates Wikipedia's guidelines regarding undue weight, as I sincerely hope you can understand. Besides the problems I have already mentioned (which need to be addressed and discussed if you disagree) with Temkin's quote, I will also expand on my previous criticism and add that he states "Brainfuck allows irrationality to blossom" though the summary box for this programming language states that it follows structured and imperative paradigms and uses static strong typing for data, all of which suggest brainfuck falls into the most consistent, straightforward, simple, and rational set of programming languages, which is true. Thus, even someone who has limited knowledge of computer science or programming languages beyond what they have read in the brainfuck article would find a contradiction here, and it is only Temkin who is contradicting the rest of the article. More problematic is that such a contradiction would needlessly confuse someone reading the "Interpretation as art" section who does not have a strong background in computer science but takes the statements in this section at face value. This is why it is crucial to make the only sensible editorial decision and remove this section from the article.

I would like to remind you that I began this chain of revisions by removing a section that has been dormant since its creation a year ago, represents the position of only one verifiable person, is suspected of being authored by said person in an act of self-promotion (a simple google search shows Daniel Temkin to be a tireless self-promoter), has only one line of content that tenuously supports its title, is written in a style that is in conflict with Wikipedia style guidelines (though perfectly consistent with one of the sources), and was created with dubious justification that is far more appropriate for inclusion in a different article (Esoteric programming language) or its own page (for which it has insufficient content). If you disagree with this, I expect you to address my arguments point by point without dismissing editorial work as "original research" and without reinterpreting my statements into new meanings. I also expect you to address all the editorial criticisms I made in the first bullet point of my original post in this talk page, which you have hitherto ignored. Since I am the first person to question the notability, quality, and neutrality of this section, I view its removal as the initial edit that begs consensus prior to change rather than your reversal of my edit. So, while we agree that there are repeated reversals going on in opposition to the spirit of conflict resolution, we do not agree on who is responsible. If the original author, who has not been seen since June 2013, chimes in and demands consensus before the section is removed, I will acquiesce. Barring that, I expect you to accept that you are reversing my edit before we have reached consensus while ignoring or dismissing my arguments and erroneously referencing Wikipedia guidelines on original research and censorship with nothing more than a simple Argument from authority to defend your overall stance on the edit and your resulting reversals. Your only response to my original edit summary was to disagree, thus claiming that "we need a postmodern interpretation of every non-traditional contribution to technical fields". If you are still holding to that, then we indeed may need third party intervention to settle this dispute. Regardless, I expect you to address the original editor's claims before reapplying any changes so that no one is subject to edit restrictions and temporary blocks. In other words, please desist from your previous behavior. Thank you for your understanding. -- anonymous supervillain 108.203.162.123 (talk) 03:10, 29 May 2014 (UTC)

Good Ghod, I'm really tempted to make an ad hominem attack on this ANON, ... pragmatically these comments look like an attempt to win an argument through through incessant bluster causing any opponents to give up because it'll take too long to address potentially perceived points without any regard to the merits of the case. This perception is enforced by the much longer response to a reply that I believe he sees as an attack on his position.

On a personal basis I most definitely see people treating BF as an art form, for example: "code golf" competitions and a BF program being reformed into an ASCII art representation of a (presumably naked) woman. This is an extension of the well known "Programming as an Art form" position and so doesn't IMO require exceptional ex cathedra citations.

For WP, the citations look good to me, the additional citation of the counterpoint argument is reasonable and expected in a philosophical arena like "Interpretation as Art". Keep the section 2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 08:43, 5 September 2014 (UTC)

If you have time enough to throw in your vote, you should have time to actually address the arguments given. If you're too lazy to do so, spare us your feelings on the matter; they aren't needed.50.195.63.26 (talk) 14:42, 10 November 2014 (UTC)

Removed references and link to Esolangs

This article listed the Esolangs wiki in the external links, and cited it as a reference in a sentence that refers to "esolangers". As an open, public wiki, I don't think Esolangs qualifies as a reliable source for referencing (see Wikipedia:Identifying reliable sources#Self-published sources (online and paper)) or as a suitable external link (see Wikipedia:External links#Links normally to be avoided). I removed the references, link, and word "esolanger", but since the site was previously accepted without question (and even praised) in discussions above, I recognize this may be controversial without editorial consensus. Feel free to revert my change and discuss here if you object. Agyle (talk) 06:19, 28 June 2014 (UTC)

From what I can tell, none of the commentary above is asserting that Esolangs is a reliable source, per se. I agree that it's not, since we normally don't consider sites with user-submitted content to be reliable. Ivanvector (talk) 14:41, 28 June 2014 (UTC)

Wikipedia is user-submitted content so foremost it is not a reliable source? — Preceding unsigned comment added by 84.119.66.146 (talk) 11:06, 7 September 2014 (UTC)

Considering the censorship in the classical media linked to the web references that Wikipedia prefers I think you're going to be hard pressed to find online sources. (They censor the word fuck) Real world sources do exist, but are quite rare for the same reason. User-submitted is likely to be your only hope despite this language's notability.

As for the Esolangs wiki, they don't have a 'Notability' clause but they do seem to qualify under the open wikis exception assuming the vague substantial number of editors is okay.

2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 06:16, 28 October 2014 (UTC)

pipes in unix - turing completeness on numbers

little mathematical functions for transformations on numers and strings can be made by the subset c to brainfuck compilers

given the functions the right file names the commands can be nested or used in shell script or called for example by a c programm

this way numberless transformations on numers and strings can be made with the subset of c programming langage brainfuck compilers

a advanced c to brainfuck compiler can for example transform variable = variable +2 to ++

a advanced c to brainfuck compiler can for example transform ptr = ptr +2 to >>

a advenced c to brainfuck compiler is not limited to the eight basic commands to map the turing completeness in math of the c programming language to the turing completeness of brainfuck

the brainfuck to asm assembers are not limited to the mnemoncs direct implicitly assigned to brainfuck they can optimize to the target processors instruction set

so long lex and yacc with you

Huh?? This is a bit incoherent. Please explain ... perhaps you're after BFBASIC 2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 06:20, 28 October 2014 (UTC)

brainfuck to c compilers could optimize strong(ly)

- i guess. cause everything is in brainfuck reduced to substraction and addition which can be transformed back to use of usual math functions. the gag like above is the pipes in unix and fork() that makes things possible for small brainfuck progs to be sequencalised or parallelized.

the set of eight instructions can be translated "mechanicaly" to their corresponding eight c commands or being transformed to compiler builders optimiziation like amazon has books for in fitting masses. the gag is the arithmetics of brainfuck is so thight to add and sub that every calculation is flattened to this level. the optimizers could substitute these to faster, not stonger but equal mighty functions. the gag is brainfuck is turing complete and think of all optimisation for compiling back to c is addition and substraction.

the combination of c to brainfuck and brainfuck to c compilers could boost apeace of software tremendes. but work work work

"Add two values" example is not consistent

Brainfuck#Adding two values starts with the simple example

[->+<]

which adds c0 (current cell) to c1 (next cell). It then says "this can be incorporated into ... as follows", but what follows is slightly different:

[
< +
> -
]

which adds c1 to c0.

Given the text "this can be incorporated into" it would be slightly easier to follow if the addition program included the simple example verbatim (other than comments) without reversing the cells. Mitch Ames (talk) 08:07, 1 January 2018 (UTC)

Truth Machine

The Truth Machine example code makes no sense to me. Nor is it explained what a truth machine is, and Wikipedia seems to have no information about it.

According to this article, the example code here clearly doesn't fulfill the requirements. I suggest replacing it with some example from here and adding a short description what a truth machine is. Sinthorion (talk) 16:38, 28 January 2019 (UTC)

"GRM - Brainfuck" by Sibylle Berg

A German SF-ish novel, quite "notable". Contains a few actual Brainfuck code snippets. Worthy for a "In popular media" section add?

Brainfugd?

Brainfugd is a variation on Brainf*** that is designed to work inside a Geometry Dash level. Wilh3lm^{Go here to trout me if I do a stupid} 10:43, 1 July 2021 (UTC)

A youtube video doesn't really signify notability (even if made by the creator), for the same reason Bloodbath or Abyss of Darkness doesn't redirect to Geometry Dash. Note that Stereo Madness is the first official level, thus why that redirects.

As for other sources, the only non-YT source I found was Wikia (a non-RS source). Someone-123-321 (talk) 04:05, 7 January 2023 (UTC)

References

Arithmetization

It seems that these changes on Jan 11 2023 were made in the attempt to describe one implementation of Brainfuck for a zero-knowledge proof system. It is my impression that those changes kind of took over the Brainfuck article, which now largely consists of how you can arithmetize the language in some context that involves prime fields. In short, a lot of assumptions here are taken for granted that the general reader cannot be assumed to know or care about. I'd like to try and revise the contributions about arithmetization so that they're preserved, but downplayed, and so that the necessary context is given. Doc Daneeka (talk) 22:33, 13 January 2023 (UTC)