This is awesome, are you planning to add more features like complex functions that are minimally sized?
A 220b spreadsheet app in HTML/JS
71–80 of 105 posts
Re: A 220b spreadsheet app in HTML/JS
#72Earlier quoted context omitted.
XSS prevention, maintainability, code reuse, good variable names, good-smelling code, readability, and using popular libraries are not "over-engineering". They are 95% of what makes someone a good employee instead of a shitty one. With modern languages and tooling, you can have the benefits of most of these things at little-to-no additional cost. If any of these require something complicated and "over-engineered", I'…
A good employee making shitty products :). I mean, security and maintainability is important, but the most secure and maintainable code is always the code that didn't get written in the first place, which makes not writing unnecessary code a no.1. way of making the result not suck.
In that case I am writing millions of lines of secure code every day. Just the other day I didn't release a wordprocessor, making it 100% secure.
Re: A 220b spreadsheet app in HTML/JS
#73I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this?…
[deleted]
Re: A 220b spreadsheet app in HTML/JS
#74I was wondering and wondering why it wasn't working for me. Colons break the script. I tried to write "TOTAL:" in a cell and none of the equations would resolve. I wanted in on the fun and I didn't get it until I relented and checked the console. :P
Pretty fun, though
Re: A 220b spreadsheet app in HTML/JS
#75Earlier quoted context omitted.
A good employee making shitty products :). I mean, security and maintainability is important, but the most secure and maintainable code is always the code that didn't get written in the first place, which makes not writing unnecessary code a no.1. way of making the result not suck.
In that case I am writing millions of lines of secure code every day. Just the other day I didn't release a wordprocessor, making it 100% secure.
Yes! So am I! It's a shame that the airlines refuse to use my perfectly secure avionics code I didn't release.
Re: A 220b spreadsheet app in HTML/JS
#76Earlier quoted context omitted.
Probably you should first consider that our browsers contain a fully capable programming system which this golfed program abuses as an expression evaluator. :-) By comparison, this C program [1] (hints are at [2]) is a stripped down spreadsheet program for X, and it only has an RPN evaluator (probably to make a room for graphing features?). [1] http://www.ioccc.org/2000/jarijyrki.c [2] http://www.ioccc.org/2000/jarij…
Hilariously Chrome offers to pass the c code through Google Translate (with predictably useless results)
Amusingly it detects that the code for the RPN calculator is in Polish. Maybe it's smarter than it seems.
Re: A 220b spreadsheet app in HTML/JS
#77I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this?…
Well, this spreadsheet as it is now isn't very much useful. In fact it is annoying at best. Only programmers will find it amusing and precisely because of how small the code is. No one is actually going to use it ever.
Re: A 220b spreadsheet app in HTML/JS
#78Earlier quoted context omitted.
I think that's probably just because it's been revised and the placeholders were added after. To be fair, it only adds an extra 18 chars, taking it up to 238-byte in size. EDIT Here it is once you add the extra property: (o=b=>{for(j in a)for(i in a)y=a[i]+-~j,b?document.write([[" "][i]]+" "):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="ABCD")
I'm more concerned with the use of the symbol `b` to denote bytes instead of `B` :)
Yeah. A 220 bit spreadsheet would be impressive. Particularly the achievement of the source length not being a whole number of bytes.
Re: A 220b spreadsheet app in HTML/JS
#79Reminds me of an IOCCC entry.
Re: A 220b spreadsheet app in HTML/JS
#80If we're using ES2015, why not save a byte? (o=b=>{for(j in a)for(i in a)y=a[i]+-~j,b?document.write([[" "][i]]+` `):eval(y+(".value"+o[y]).replace(/[A-Z]\d/g," +$&.value"))})(a="ABCD")
of course! Thanks, I'm adding this enhancement on github!