Let's build an entire programming environment around Brainfuck
malone.cc
malone.cc
But yes, I would agree with the general sentiment of experiencing the world. For me, there is not much that is more satisfying than exploring - be it traveling to new places, climbing a mountain or just trying something new.
That said, if this project removes the boredom and is interesting/fun to the OP, there is value in that as well.
Since Antigua isn't too far off the beaten path, let me throw out Colombia.
Spend the night in a hammock near the ocean.
http://wikitravel.org/en/Tayrona_National_Park
Party into the night:
http://www.lonelyplanet.com/colombia/northwest-colombia/mede...
Your comment comes off as a little bit condescending and presumptuous. There's this underlying judgement about the relative worth of writing a Brainfuck interpreter and environment versus drinking in some bar in Guatemala or starting a company, like the latter is obviously a better use of time and energy. Aside from the fact that doing the things you mention aren't mutually exclusive with this little project, it's really tiring to hear (older) people constantly beat the drum of "you're young! go travel! drink!" on top of the "start your own company!" startup mantra. Maybe you wish you did more of those things when you were younger, or maybe you wish you were doing more of them now, and maybe I will wish the same thing when I'm older...
But they are absolutely not for everyone. I think it's disingenuous to just throw out "take that energy and try to build a company" as an alternative. Not everyone has it in them to do all the schlep work required to succeed at their own startup, so why assume this person hasn't considered it and chosen not to follow that path? Furthermore, I would personally prefer to tinker with a Brainfuck implementation than spend any amount of time in any bar, even it's in Guatemala or Colombia. I usually find them noisy and unpleasant, and I would find "partying the night away" to be a boring waste of time. But I would never suggest someone else shouldn't spend their time that way because that would be assuming a great deal about what's important to them.
Maybe this was just a little flip remark on your behalf, not meant to be taken seriously. I'm probably projecting a little bit, and reacting to something you may not have intended to imply. For that, I apologize again.
As someone who's just read your comment, I'd like to say: calm down, and re-read the parent comment with an open mind. It's dripping with life experience.
You can always build another skateboard ride-sharing site with photo uploads and Raspberry Pi integration later. Now might be your best shot at Brainfuck."
http://en.wikiquote.org/wiki/Augustine_of_Hippo
And the idea of traveling isn't to spend it all in a bar. Anyway, spend your time as you please...
Why not? I'm not saying I disagree, but your argument is weak. Sometimes it's not the accomplishment that matters, but the attempt. Whether the attempt at these actions is beneficial or not hasn't been addressed at all. That seems to me to be an important omission in an discussion about what are essentially life experiences.
But I would never suggest someone else shouldn't spend their time that way because that would be assuming a great deal about what's important to them.
In some respect, what important to them does not matter. Who they are and what they feel is important at that moment may very well be small subset of what they will consider important throughout their life. In the dispensing of advice for the purpose of changing someone's outlook on life, whether their current outlook agrees with it or not is irrelevant.
I don't know if this is a "when you have a hammer, everything appears to be a nail" - but I continually am shocked at how few of my six-figure salary colleagues in the IT industry (networking, unix, systems integration) are incapable of slicing and dicing a large text file and reporting on it. Activities that take them the better part of day in Excel, can sometimes be done in a few minutes with a fast awk script.
Knowing awk (and all the regex associated joy) has brought me (personally) great pleasure, and I'll die a happy man knowing the time I put into it was well spent.
We each have to find joy in life where we can.
That's my interpretation, anyway. Not that hobbies are bad, but that this is gonna be a life-consuming hobby, will likely detract from other pursuits, and may not pay off as well as OP thinks it will.
Perhaps I missed something in the post, but I don't see a "shitton" of work there.
The first step is easily a one weekend (if not one day) project. None of what was described is particularly difficult, complicated, or labor intensive. I wonder if people are making assumptions about all sorts of fancy extras that the post doesn't mention being included.
That's the time for pure code-work. Thinking/design/testing will eat up more time, but not that much more time. As described it's a pretty reasonable weekend project to last a couple months.
a) I'm going to be doing this "work" (which, okay yeah it is) full-time or even constantly, when I'm probably just going to hack on it for the next few months or years; whenever I've got a coding itch. I doubt I'll ever go into crunch mode on this or get "burned out". I'll just put it aside for a while and do something else.
b) That I can't just say "Whelp, it was fun but I'm done" at some point during the project and find something else to do. There's no hardcore commitment here; like all projects, everything beyond the first step is a pipe dream.
I get what you're saying though and it could definitely be a shitton of work that's probably not usable IRL. But it's still a fun plaything.
In the end, I believe Michael Ende described it the best in "The Neverending Story" (the book, not the movies). The essence of what I would recommend to anyone is expressed by the words on the back of AURYN: "Do what thou wilt". As Bastian is told, it's not about doing anything you want, it's about finding out what it is that you truly wish for, "and nothing is more difficult".
Maybe OP will spend years working on this project and end up realizing that it was "a waste of time" and that what he really wants is something else. But even then, it might end up being more valuable to him than doing things you recommended. Who knows?
To me, coding is like painting or cooking. It's a fun activity done for leisure and self-improvement. I do silly things like code Brainfuck environments because I mostly do these things for me.
I'm not in a startup or building a company because I don't want to give my leisure activity a work stigma. I don't want to code for money because it'll strip away everything I like about programming: the fun of untangling a problem, the casual pace of piecing together a solution and the independence of being able to code whatever I want whenever I want.
In the future I can see myself doing open source projects or writing professionally but I can't see myself coding for 9 to 5 or swapping out my silly activities for a dayjob where I build someone else's thing.
I don't agree with the "I'm older and smarter than you" and "you should travel the world drinking on exotic beaches" points. That's not everybody's bag. Though, I would tend to agree with about the value of one's time and energy.
The thing about this project is that you could just switch the language from Brainfuck to literally anything that isn't an academic gag. You would do the same work and gain the exact same experiences. In the end, in addition to simply the learning experience, you will have produced something that may likely be usable to many people. Of course you won't be able to get the same lulz as you would telling people that you spent a year of your life writing a Brainfuck interpreter.
(Direct link to the code: https://github.com/haberman/jitdemo/blob/master/jit3.dasc)
I added some optimizations using Flex to identify patterns, and got a 3.8x speedup on the Mandelbrot benchmark -- https://github.com/rmmh/beefit
You may have tried this already, but where you have:
mov al, byte [PTR]
movzx eax, byte [PTR]Partial register stalls are where you write part of the register, then read the full register:
mov al, byte [PTR]
add ebx, eax
mov al, byte [PTR]
add byte [PTR+3], al
I got jit4 about as far as is reasonable for a single-pass compiler, but I intend to implement a proper BF->IR->ASM compiler to implement some more complex multi-pass optimizations I have in mind.
Good point about the stall -- I always thought that partial register stall happened at the point that you do the partial write, since the logical contents of the register now depend on its previous contents. I didn't realize that the dependency logic was sophisticated enough to allow the partial read without depending on the entire register's value.
It'll be neat to see what he comes up with.
I think it's that very reason he's submitting it so early.
- telling everyone motivates you: you made a public commitment, you get early feedback, "if your idea is any good people will reject it at first"
- don't tell anyone motivates you: the idea is yours, you want to build something beautiful and show to the world, you don't like to be criticized when starting up
The conclusion of the study was that people are more likely to stick to a goal they keep to themselves. This is because often telling people a goal they will reward you with praise as if you already achieved it making it prematurely gratifying which causes you to lose motivation.
Also from my own experience public commitment is a bad motivational tool. This is because the motivator of public commitment is usually fear (failure etc) and fear is a terrible mindset to draw motivation from which (in my experience) can cause a lot of procrastination.
Fixed BTW
1) How long have you been insane?
2) Static or Dynamic typing?
5) ???
6) Web framework?
5) !!!
6) I am but a mere mortal, sir.
2) Integers! Strings are integers, arrays are tapes of integers, etc... I guess this means it's dynamic, but at the bottom levels I'm not (yet) concerned with typing.
So instead of: +++++++. You would write 7+. or something similar... can't remember now.
I never quite got around to functions, but there is basic support for arithmetic, for loops and rand()
[1] https://github.com/qix/c2brainfuck [2] https://github.com/qix/c2brainfuck/blob/master/samples/beer.... [3] https://github.com/qix/c2brainfuck/blob/master/samples/beer....
It would be pretty trivial to create a uP out of high-speed logic that would execute each instruction in a single clock cycle. Add a PIC uC to actually load the program memory and you could have a nice little console machine.
As a side note, I've spent most of my career building uC systems that communicate via RS-232 or RS-485 (if they communicated with the outside world at all), so imagine my surprise to find I couldn't buy a laptop with a serial port. It's like the end of an era (yes ... I know about USB-to-serial adapters).
Beyond that, it's far too young for me to decide.
I suppose it works but convention seems to be 30,000+ bytes and 8-bit cells. Of course, getting pedantic about brainfuck conventions is a bit beside the point (like Orthodox Discordianism). I just want to know if I'm correct and, if so, I'm curious about what is gained through such nonconventional decisions.
I get why you excluded negative numbers. I was wondering if I was correct in understanding the cell size to be 2 bytes because it's typical for it to be 1 byte.
Am I correct that - on a cell at 0 (or + on a cell at MaxVal) is a no-op, just like < and > at the end of the tape?
Also, we will actually be breaking 30,000 cells. Just not with a single tape :).
more generally, compilers are fun to learn about. i found Jack Crenshaw's "Let's build a compiler" series a good starting reference and source of inspiration [1].
i built a brainfuck to GNU assembly compiler in brainfuck. to be able to write that compiler, i first built a higher-level macro language that could target brainfuck, and wrote a compiler for that. the macro language was implemented as a horrible DSL in python [2].
later i built an implementation in haskell that could parse and compile the macro DSL to brainfuck, so things ended up entirely python-free [3]. Haskell's Parsec parser combinator library was fun to learn about too [4].
[1] http://compilers.iecc.com/crenshaw/
[2] https://github.com/fcostin/abfc
In addition to the basic language it had a stack and, with a bit of c preprocessor trickery, i devised a hackish way to have macros (despite the cpp man page saying not to use this for anything but as a c preprocessor).
Which is at least as weird, more serious, further along, and orders of magnitude more ambitious.