Live data from Hacker News

A 220b spreadsheet app in HTML/JS

xem.github.io

61–70 of 105 posts

Re: A 220b spreadsheet app in HTML/JS

#61
post #33

Earlier quoted context omitted.

yes hack yourself. bravo :) I guess you would have to sanitize when you save and/or load the spreadsheet

> 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…

> Either you have a dedicated expression parser, or you run it directly throgh eval. There is no reliable middle ground.

While there is no safe middle ground, using eval directly is the worst case; it's not a case where those extremes reliable and there is greater danger in between.

That being said, rejecting everything that fails an expression parser is a form of sanitization.

Re: A 220b spreadsheet app in HTML/JS

#62

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

No post body was provided.

Re: A 220b spreadsheet app in HTML/JS

#63
post #56

Earlier quoted context omitted.

>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

Sure, i explained it here earlier today: https://github.com/xem/sheet/issues/4

Re: A 220b spreadsheet app in HTML/JS

#64
post #55

Earlier 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)

Language detection works on language trigrams, and are trained on human language. I bet punctuation is stripped during preprocessing. So it's not surprising that code will have false positives.

Re: A 220b spreadsheet app in HTML/JS

#65
post #55

Earlier 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)

[deleted]

Re: A 220b spreadsheet app in HTML/JS

#66

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

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'd instead describe it as "bad engineering".

Re: A 220b spreadsheet app in HTML/JS

#68
post #66

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

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

No.

Rule one is making code that works correctly and quickly, in a short about of time. This is 100% of the job.

If you think that "maintainability" and "readability" and "popular" libraries, and "code reuse" and "good variable names" and code that "smells good" to you, help someone do that, then great: That's an argument we can have just by pointing to anyone who gets rule one without those things.

However.

There's another kind of person - and there's a lot of them - who thinks those things are important by themselves, and that putting those things ahead of what I think are rule one is ever acceptable.

The number of times I've heard some "experienced" programmer say with all earnestness that we should ask for another 1/4 million dollars of tin so that he can use his "clean" (but slow) algorithm makes me wary of anyone who uses those words you just used in seriousness.

That's the person the parent comment is mocking.

Re: A 220b spreadsheet app in HTML/JS

#69
post #66

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

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.

Re: A 220b spreadsheet app in HTML/JS

#70
post #18

Hello World, I'm xem, author of this mini app, but standing on the shoulders of giants: it's inspired by http://aem1k.com/sheet/ which was inspired by http://jsfiddle.net/ondras/hYfN3/ Cheers to all the JS codegolf team who teached me this noble art and continue to learn new tricks everyday with me! You can find a list of all our mini apps here: https://gist.github.com/xem/206db44adbdd09bac424

Perhaps they were actually dwarves? :)
Post reply on HN