81–90 of 154 posts
In the same vein as this program, there's JS1k. Some of the stuff on there is also really amazing.
Earlier quoted context omitted.
I think it's helpful to consider that this program in 672 bytes of machine code rather than source code or assembler. That helps the comparisons to English text seem a little less jarring: if my words were expressed as 8bit bytes rather than a series of byte sized chars you'd see a lot of compression in my communication. He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so…
> He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so it doesn't count toward the 672 byte limit. I'm missing something here, but if something is never loaded in the memory, why should be counted? Why do you consider that a part of the program at all? Can you please also provide more technical details, since I don't understand what you mean?
Wow, that's amazing. I love programs written in less than a kilobyte. Personally, I developed a CSS framework that is only 995 bytes (not to compare it to this program) - http://mincss.com/ . In the same vein as this program, there's JS1k. Some of the stuff on there is also really amazing.
hehe.
Actually though, as someone who learned CSS with the rule "Use Divs! No Tables!" What does a page with less divs even look like? What are the workhorses for page layout?
Earlier quoted context omitted.
A better analogy would be 'greatest movie ever made' was so because it was done on a budget of $1000. Better analogy in context of this thread that is
Why? Seems like a much poorer analogy to me, since it is trivial to make a movie for much less than that. It falls into the same trap as the commenter above, the 'greatness' is due to the quality of the program, rather than just making it exist at all.
The greatness of a movie is not measured by its budget, nor is the greatness of a program measured by its number of lines or memory footprint.
Do you see now why your analogy is not as good?
Earlier quoted context omitted.
Why? Seems like a much poorer analogy to me, since it is trivial to make a movie for much less than that. It falls into the same trap as the commenter above, the 'greatness' is due to the quality of the program, rather than just making it exist at all.
The greatness of a run mile is measured by how fast it is run. The greatness of a movie is not measured by its budget, nor is the greatness of a program measured by its number of lines or memory footprint. Do you see now why your analogy is not as good?
Holy smokes... blown away. 1K RAM? less then most email's we write... Now'a days rockstars and Ninja's are the glorified ruby guys who "seemingly" do Ruby/django magic... This is what counts...This is the real deal...
Weeeell... The entire point of computers is to be able to do work that would be too tedious for humans. Computers exist so people can be lazy. Making better programming languages so programmers can be lazy is kind of the whole point of the job.
Really? News to me.
Like the entire point of cars is to take you on journeys that would be too tedious to walk?
Also pertinent: Peter Jennings' Microchess for the 1K Kim-1. His page says it "was the first game program sold for home computers", shipped in 1976. http://www.benlo.com/microchess/
On a side note, I wrote one that ran on a PIC16 and fit into 4K of flash, while the part had only 176 bytes of RAM. It played over the serial port in a terminal. The 4K is not impressive, but I wrote it in C with a compiler that didn't support recursion because the stack is for return addresses only and is only 8 levels deep. IIRC I could do a 5 level minimax search on it.
Earlier quoted context omitted.
The 4 minute mile was amazing because of the four minutes, not because someone managed to run a mile. Amazing feats in the face of incredible constraints are inherently worthy, I'd say.
A better analogy would be 'greatest movie ever made' was so because it was done on a budget of $1000. Better analogy in context of this thread that is
Earlier quoted context omitted.
Just for context, your comment: 1452 bytes, well over twice the size of this chess program.
I think it's helpful to consider that this program in 672 bytes of machine code rather than source code or assembler. That helps the comparisons to English text seem a little less jarring: if my words were expressed as 8bit bytes rather than a series of byte sized chars you'd see a lot of compression in my communication. He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so…
Estimates of information density for English are as low as 1.5 bits per character, giving 272 bytes in that comment.
The information density in machine code isn't 1 bits per bit though, because of the distribution of which opcodes are used, so the 672 would also drop.
So I think the analogy is a pretty good one, whether exact or not, some of the comments on this page contain more information than ZX81 chess.
Earlier quoted context omitted.
> He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so it doesn't count toward the 672 byte limit. I'm missing something here, but if something is never loaded in the memory, why should be counted? Why do you consider that a part of the program at all? Can you please also provide more technical details, since I don't understand what you mean?
In a way you're right, the executable is definitely within bounds and if that is your definition of the program, it's small enough. If you count resources that are necessary to make the program run, however, you'd use a different metric.
http://en.wikipedia.org/wiki/ZX81
24 lines of 32 characters. 768 bytes usually cleared and scrolled away as you type. The user just has to load the cassette and play. Even if the program was developed on the Cray (it was not) everything needed for the program to run is less than 1K. Please explain your sentence "If you count resources that are necessary to make the program run, however, you'd use a different metric."
See the proof:
https://archive.org/stream/popular-computing-weekly-1982-07-...
"The tape loads every time, without problems, in about 30 seconds." The cassette speed of ZX 81 was 250 bits per second, 30 seconds is less than 1 KB, and the sync header (the bits that don't carry the program) were certainly also counted in the given 30 seconds by the reviewer.