Talk:NetFuck

I disapprove. Phantom Hoover 11:02, 23 May 2011 (UTC)

Disapprove to WHAT? You could be a bit more precise. And since many people have written BF derivates, this is a good extension. Also, in general, it is just an esoteric language like "Ook", so nobody has to APPROVE to an esoteric language. If you have CONSTRUCTIVE critique, please let me know and I will think about how to improve this work. Me personally I like the idea that BF can communicate with other processes/computers to work on a doulbe-I/O ("3D"). --87.165.157.233 18:59, 23 May 2011 (UTC)

And since many people have written BF derivates, this is a good extension.

Wait, how does this follow? —ehird 19:46, 23 May 2011 (UTC)

I do not know how to say this. In German I would say to it "Es hat eine Lebensberechtigung". --87.165.157.233 23:49, 23 May 2011 (UTC)

"It has a right to life"? Is Google Translate translating this incorrectly? —ehird 19:52, 24 May 2011 (UTC)

If it is anything like the Norwegian "livsberettigelse", then the connotation is different, somewhere between right and reason. --Ørjan 23:34, 24 May 2011 (UTC)

The presence or absence of Lebensberechtigung for anything, whether esolangs or anything else, is neither predicated on nor in any way influenced by how many people have done it before. — Timwi 00:37, 26 May 2011 (UTC)

I disapprove of almost all Brainfuck derivatives on principle; the wiki is inundated with them, and yours simply follows the tired old formula of "add some instructions to BF to do <feature>", and it doesn't even do it well. Phantom Hoover 19:50, 23 May 2011 (UTC)

Please note, I did not say that NF is better than BF. I do not say that this is a revolution or something. I respect your disapprove to BF derivates in general. I developed NF to get new experience in developing applications in the esoteric BF language which can connect via network/IPC and play music with as low command-set as possible. If you have other ideas how to do it well, please let me know. --87.165.157.233 23:49, 23 May 2011 (UTC)

sigh You have implemented neither networking nor IPC. You have created a system to allow 2-way communication along a static channel between two NF programs. No way is given for the program to control where it sends to or receives from; I can only assume this is determined before runtime. To do it well, you might want to actually learn what words mean before making a language based on them. Phantom Hoover 00:00, 24 May 2011 (UTC)

Actually, I want to implement a NF interpreter sometime. This will include "networking" and implicit "IPC" (IPC in the sense of a localhost-localhost communication). Please, read my article again. There I have written that the SETUP of the connection has to be established by client and server which is running NF. Actually, I do know what these words mean, as I studied network technique 1 year in the University of Applied Sciences in Mannheim as part of my Bachelor study of computer sciences. I do know how to use pipes, IPCs, shared memory, traps, rendevouz, mutexes and deadlock-free communications.

Back to topic, all in all the process can be described as:

1. Client runs NF interpreter with program X

2. Server runs NF interpreter with program Y

3. Client and Server are set up by the User (using a GUI which the interpreter serves resp. CLI-parameters). The user enters IP-address or FQDN hostname, or also localhost. It is up to the interpreter if it checks if a NF interpreter is listening at the target side or not.

4. As soon as the setup is done, the NF program will run (and probably wait for the other side to join the connection)

5. The other side now also runs and both programs send/receive cell-values according to the connection settings made before.

It is likely that such an interpreter uses CLI-parameters (nf.exe myprogram.nf 127.0.0.1:8081) rather than a GUI. The connection between the 2 running NF programs will then be static until one of the programs terminates.

If a NF 1.1 program with 2 threats is running and connecting to the localhost, the effect is the same as IPC, as the two threats are communicating with themselfes.

Comments are welcome.

--87.165.182.97 19:48, 24 May 2011 (UTC)

I defer to your astonishing experience with networking; obviously the apparent stupidity of this language is only a product of thinking that networking should at least allow a program some control over what it connects to, a clear sign of my neophyte hubris. Phantom Hoover 21:20, 24 May 2011 (UTC)

At the risk of stating the obvious or repeating what others have said... It is clear that the author is very much into networking, but very little into esolanging (or programming language design in general). NF’s design goal is clearly not that of a programming language — it is more like a scripting language for an external environment, namely, the environment that sets up the network communication outside of the program that is written in NF. Imagine how useless C#/C++/Java/etc. would be if it were like that! As such, I agree that this is rather badly placed on this wiki, even though I must admit there is no separate “esoscripting” wiki to provide a better place... — Timwi 00:45, 26 May 2011 (UTC)

I am new in "esolanging", but I am not new in programming languages. I develop in different programming languages and I developed professional software for companies as sidejob beside my university. But well, NF is NOT a programming-language. It is an esoteric language which extends BF. All in all, NF is just a notation of a finite state machine, more exact a Turing complete machine which can communicate over 2 I/Os (console AND network) - both, NF and BF do not need any I/O to be Turing complete, of course. You are right, that the NF interpreter sets up a network connection, but this IS the interpreter, not an environment. A classic brainfuck program is also "useless" if you don't have any interpreter which interprets what +, -, < or > means. I have seen many other BF derivates in this Wiki and I do not think that NF is an outsider. Badder BF derivates exist which also have found a place here. But this time, NF brings a new concept with it. What is your exactly problem with the "environment"? Every eso-language like BF or Ook needs an interpreter to run. So does NF, with the difference, that the interpreter has to establish a network connection, while a classic BF interpreter only needs to setup the console I/O with the stdlib. Is it your problem that the connection needs to be established by the interpreter, while classic BF programs only need the OS's console interface? --80.139.110.66 19:52, 26 May 2011 (UTC)

"All in all, NF is just a notation of a finite state machine..." You should probably stop trying to defend this, rather than digging yourself deeper. Phantom Hoover 20:25, 26 May 2011 (UTC)

I still don't get your problem. This is so petty and you search every error in my sentense to critisize me... I have already written a full functional interpreter in QBasic and developed simple chats over nullmodem, so I don't really see why NF should be so worse in your opinion. --87.165.166.97 00:34, 1 June 2011 (UTC)

NF is a programming language; esolangs are esoteric programming languages. Programs are, after all, just notations for Turing machines in the general case. —ehird 20:30, 26 May 2011 (UTC)

That is right. I do not know where the problem in the whole discussion really is... --87.165.166.97 00:34, 1 June 2011 (UTC)

I was simply pointing out an error in your post. —ehird 01:35, 1 June 2011 (UTC)

Update: By thinking a bit about it I can respect your concern, that the NF program code ITSELF cannot control to which client it connects to. The main problem is that over a network connection you could connect to "anything". And the program can only send over a predicted static connection. I can respect this issue. But thanks to your comment, I had a great idea.

In general, NF is just BF with a second I/O port included. The LANGUAGE itself just defines these 2 additional send/receive OPs ^ and v. The INTERPRETER itself decides HOW to send/receive these values. My idea was to use TCP/IP in general. But on the other hand, the interpreter could also send the data over a simple nullmodem cable on COM port. There are 3 great advantages for this: (1) It is much more easier to implement, especially for DOS operating systems. (2) The NF program has NO other choice where to connect to! There is just one partner at the other side. (3) Different other problems which exist for the complex networking over TCP/IP (like possible DNS-resolving and port-listening) will then are omitted because of the nullmodem cable.

Still, there can be an interpreter application which implements the 2nd I/O to send over TCP/IP with CLI parameters.

What do you think about the idea that the LANGUAGE concept of the 2nd I/O, defined as ^ and v would be implemented as nullmodem-cable connection by default? I would like to hear your opinions for this new idea. --80.139.110.66 20:19, 26 May 2011 (UTC)

Prize

What is the prize for implementing the interpreter and Pong game? —ehird 19:58, 24 May 2011 (UTC)

Currently, no finally defined, but I think it will be free (ad-free) webspace. --80.139.110.66 19:52, 26 May 2011 (UTC)

A shame. —ehird 01:36, 1 June 2011 (UTC)

Your Wiki would be much better if you wouldn't insult your users... --217.92.21.71 10:28, 4 June 2013 (UTC)