Talk:Brainfuck

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)

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:

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?

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)

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 at the Open Directory Project. 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.

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)

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

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)