Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 220b spreadsheet app in HTML/JS

xem.github.io

Post reply on HN
Print view View original

51–60 of 105 posts

Re: A 220b spreadsheet app in HTML/JS

#51

Post by xem »

oddlyaromatic wrote: post #49
projectant wrote: post #43

I'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?…

This seems to be code golf, which would answer most of these questions I think. Maybe I'm missing some sarcasm in your comment, it's early!

I'll take his comment as a joking sarcasm anyway.

Re: A 220b spreadsheet app in HTML/JS

#52

Post by oddlyaromatic »

xem wrote: post #51
oddlyaromatic wrote: post #49

Earlier quoted context omitted.

This seems to be code golf, which would answer most of these questions I think. Maybe I'm missing some sarcasm in your comment, it's early!

I'll take his comment as a joking sarcasm anyway.

Yes! It's confusing seeing as it is the top comment but clearly everybody gets it and appreciated the joke. It's perhaps just too chillingly accurate ;).

Re: A 220b spreadsheet app in HTML/JS

#54

Post by vidarh »

michaelwu wrote: post #47
projectant wrote: post #43

I'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?…

All of the things you mentioned are best practices when building something that you want other people to use in production. The author was trying to build this with the absolute minimum amount of code as an exercise so I don't think any of your comments here apply.

I think the last line makes it relatively clear that the preceding statements were meant as a joke.

Re: A 220b spreadsheet app in HTML/JS

#55

Post by vidarh »

lifthrasiir wrote: post #12
mbertschler wrote: post #5

Yet our browsers blow the page up to 100 or 1000 times that.

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)

Re: A 220b spreadsheet app in HTML/JS

#56

Post by hjalle »

Arnavion wrote: post #45
spectaclepiece wrote: post #44

Yesterday I was blown away by both tetris and snake golfed out to this degree and now this. I feel like this is the modern reincarnation of obfuscated c. Can somebody explain to me how: "a[i]+-~j" is the same as "a[i]+(j+1)" ?

>Can somebody explain to me how: "a[i]+-~j" is the same as "a[i]+(j+1)" ? -(~j) = Twos complement of the ones complement of j Twos complement = ones complement + 1 So twos complement of (ones complement of j) = ones complement of (ones complement of j) + 1 = j + 1

Am I missing something or isn't the "+" unnecessary? i.e. a[i]+-~j = a[i]-~j

Re: A 220b spreadsheet app in HTML/JS

#57

Post by sandGorgon »

xem wrote: post #42
murftown wrote: post #32

If, like me, you're trying to figure out how this works, I've expanded it here to make it more readable: https://pastebin.com/1c72BYK1

Hey, thanks! Would you like me to write a commented version of that code? A lot of black magic is still hidden in every line :)

That would be awesome!

Re: A 220b spreadsheet app in HTML/JS

#59

Post by vog »

usrusr wrote: post #46
vog wrote: post #33

Earlier quoted context omitted.

> I guess you would have to sanitize when you save and/or load the spreadsheet Sanitizing? No chance. Either you have a dedicated expression parser, or you run it directly throgh eval. There is no reliable middle ground. Decades of security failures of so-called "sanitizers" show this pretty clearly. (Even if you manage to create a perfect sanitizer today, wait a few months, new features are added to the browser, and…

Is there really no middle ground? Sanitizers fail because they try to salvage the clean part, only blacklisting some possible inputs. But what if you turn it around? Only send to eval what fits through a matcher for a very small subset of the language. The matcher can even allow invalid inputs if you know that eval will safely reject them (think unbalanced brackets). That matcher will be much easier and safer to impl…

> Only send to eval what fits through a matcher for a very small subset of the language

That's exactly what I meant by "dedicated expression parser".

(Not sure why you name it "matcher", though. Please be aware that a regex-based matcher will almost certainly fail for that task. You usually want a grammar, i.e. parser, which is more powerful, and shorter, and easier to read and to verify.)

EDIT: To those who downvoted my clarification, do you care to elaborate?

Re: A 220b spreadsheet app in HTML/JS

#60

Post by cat199 »

vog wrote: post #59
usrusr wrote: post #46

Earlier quoted context omitted.

Is there really no middle ground? Sanitizers fail because they try to salvage the clean part, only blacklisting some possible inputs. But what if you turn it around? Only send to eval what fits through a matcher for a very small subset of the language. The matcher can even allow invalid inputs if you know that eval will safely reject them (think unbalanced brackets). That matcher will be much easier and safer to impl…

> Only send to eval what fits through a matcher for a very small subset of the language That's exactly what I meant by "dedicated expression parser". (Not sure why you name it "matcher", though. Please be aware that a regex-based matcher will almost certainly fail for that task. You usually want a grammar, i.e. parser, which is more powerful, and shorter, and easier to read and to verify.) EDIT: To those who downvote…

> EDIT: To those who downvoted my clarification, do you care to elaborate?

you are probably making too much sense.

Post reply on HN