I don't know too much about programming, but I am curious about this: Is it possible to make a 4chan (or any *chan) site, however simple it may be, in fortran? I seriously doubt it, but hey, that's what I asked for.
Well if you can write CGI programs in FORTRAN. I think you can, but I'm not sure. FORTRAN has modern filesystem access routines, right? So images and such could be done. Perhaps even an interface to a SQL database.
But it'd be like kicking dead whales down the beach.
>>2
Yeah, the most I was really expecting would be something like as bad as the tandy strongbad emails. Something solely text-based.
Do it in lisp instead! (it has been done before in lisp actually)
There is a language called COBOLscript. No foolin'.
>>6
some idiot on /prog/ did it but then gave up after i kept finding ways to break it.
Hi, as a Fortran programmer I'd like to give my input on this.
Fortran has modern filesystem access and can call library functions. (In some special cases you may need to write a set of hooks in C/C++. This is an issue of how Fortran functions expect to have parameters passed to them and is more of a problem when mixing imperative Fortran code with object-oriented code in another language. Fortran calling C functions is rarely a problem. Also some compilers can work around this.)
You can indeed write CGI, and you can interface with MySQL or other database systems. (Oracle?) Alternatively you could of course give your board its own special way of storing posts.
So if you really wanted to you could implement a full-fledged imageboard with cross-board linking, animated thumbnails, and other such advanced features, that would be capable of handling heavy traffic loads - something that could be the codebase for a huge site like 2chan or 4chan.
But, there are real reasons all these boards are written in PHP, Perl, etc.
You could just as well code a "2ch-style" or "2chan-style" board in Fortran as you could in C or Ada or whatever, but in the end all of these would end up being fairly complicated programs and probably end up being maintenance nightmares.
Despite the performance costs of the "script infrastructure" it's serving us just fine.
Here's a much more interesting question: Can you do it in INTERCAL?
The real question here is: can it be done in Brainfuck?
>>10
Not with the standard version. However with a custom BF interpreter that allows for file I/O, it's certainly possible.
Actually I might do this some day for the hell of it.
s/dick/vag/
>>13
BrainSub is an abomination of BrainFuck, and its named subroutines destroy everything BF stands for.
>>15
True, I thought that was pretty lame, but I looked through the rest of that wiki category and didn't see any other BF derivatives that handled file I/O.
It'd be trivial to extend an existing implementation to add file manipulation without all that other bloat.
Essentially what it needs is a way to define the beginning and end of a string to use as a filename, functions to open a file for reading or writing defined by the string you've set, close a file, and change the standard input/output stream to point to that file.
Suppose we used ^
to set a string-start marker, ?
to read a file, !
to write, and @
to append. Then you could do something like:
^ first character is here
o --[>-<-------]>+>
u ----[>+++++<--]>->
t ----[>+++++<--]>-->
p --[>-<-------]>++>
u ----[>+++++<--]>->
t ----[>+++++<--]>--
!
And now your .
would write to "output".
You could then adjust the file operations so that after opening a file they would write a file handle into the current cell. Then, and assuming since this is the first file, our file handle is probably going to be #3 (since 0/1/2 are predefined to stdin/out/err), if we immediately did a .
after the !
, our file would get a \x03 written to it.
Now we just need two more commands, one to close a file when we're done with it -- say, $
-- and another to set the current handle that .
or ,
operate on -- perhaps :
to change the write handle and ;
to change the read handle.
After that, you'd be set to make a Brainfuck-based imageboard.
BrainFuck "stands for" having a compiler that is less than 256 bytes. In that sense, pretty much every single implementation of it ever, except the original, has been an abomination.
>>18
Well, that's just, like, your opinion, man.
OP IS A FAGGOT JUST GO ON /b/
> Wow. I've seen useful forth compilers in less than 256 bytes.
Liar, post code.
I hope you mean compiled and not the source code less than 256 bytes. (which is still very few, but with perl/j/k... who knows)
The 8501 has 256 bytes of ram and runs forth. There are other PICs with less memory, but they usually run a "hosted" forth (e.g. a 3-inst-forth variant), so I wasn't going to count them.
Since Forth's source and code forms are equivalent (like assembly), I don't think it matters whether it's compiled or not. Pretend it's source-code form is the "annotated" and "commented" form.
http://www.nada.kth.se/~matslina/awib/
is the only BF compiler I've seen written in BF and frankly it's quite large. All of the tiny BF compilers I've seen are written in C which seems more to demonstrate the compactness of C rather than the compactness of BF.
Comparing Forth and BF makes BF seem quite bloated. >>21 is right. BF is a childs toy- useful for stretching the mind and for personal amusement. It is not a demonstration of anything small or compact though...
The 8501 also has much shorter instructions than a modern 32-bit processor, making it much easier. The original Brainfuck compiler was something like 240 bytes on m68k, with file format and operating system overhead, and generation of valid executable files, not just compiled code in memory.
You're entirely missing the point. First, the original Brainfuck compiler wasn't written in C, it was written in Assembly in order to get it small enough. And yes, it was a demonstration of something small and compact.
Here is the original implementation: http://aminet.net/package.php?package=dev/lang/brainfuck-2.lha
Note that the description is "240 byte compiler. Fun, with src." The README further states:
> Yes, I squeezed another ridiculous 56 bytes out of the compiler. They have their price, though: The new compiler requires OS 2.0, operates on a byte array instead of longwords, and generates executables that are always 64K in size. Apart from that the language hasn't changed. Again: *** OS 2.0 required for the compiler and the compiled programs ***
The interpreter works fine under any OS version. And yes, thanks to Chris Schneider for his ideas how to make the compiler shorter.
I stand corrected!
faggots
FAGGOTS
gAFFOTS
magorts
MAGNOTS
foghats
Frigates
graphites
FIGMENTS
daggots
Sagats
fORgeTS
ffonagorts
>>40 GETS
feghoots
Spigots
FOOGERTS
frogettes
Baguettes
fat gits
FAT GITS
Gadgots
If you want to be cool and challenge yourself, write the website not in "modern" Fortran, but in Fortran 66 or Fortran 77 <- DUBS languages!!!
7^2 GET
check out Factor http://factorcode.org/
Well, it's obvious there is just not enough love for trans-fortran programmers. Every link google knows for "THE" operation (C->F translator, so you can compile regular cgi/php) is 404.