next challenge, Word in 30 lines
A spreadsheet in fewer than 30 lines of JavaScript, no library used
201–210 of 274 posts
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#202Earlier quoted context omitted.
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…
I agree, saying "Wow, this is a viable and useful language" because you can do something in just a few highly unreadable lines seems... like a pretty odd judgment. It'd be a bit like saying that C is a great language because someone wrote a raytracer that fits on a business card[0] using it. [0] http://fabiensanglard.net/rayTracing_back_of_business_card/
its called "Abstraction"
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#203Earlier quoted context omitted.
Yeah, I'm aware of this and emscripten. So far, to me, they don't look viable for DOM manipulation.
Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your pe…
Consider ES6 too. It also does a good job at removing some Javascript quirks and adds sensible looping constructs, list comprehensions, generators and generator comprehensions, proxies, rest/spread arguments (removing the need for the magical `arguments` identifier), classes (just sugar for what we already wire up with prototypical inheritance), modules, fat arrow functions etc.
No help on the DSL front though - still stuck with various kinds of brackets and parens.
On the other hand, it doesn't do the utterly horrible mistake of conflating variable declaration and variable assignment while forbidding shadowing, resulting with surprise bugs and spooky action at a distance.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#204Oh well, didn't expect it to work but I had to try it: 0.1 + 0.2 = 0.30000000000000004 Awesome work either way. Would be nice to know how many lines of code Lotus 1-2-3 had.
Number of lines of code in Lotus is unrelated for many reasons which I hope are obvious.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#205Earlier 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.
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…
At a general level, the recommendation to avoid `eval` and `with` is worth heeding, particularly for people who are new to the language.
You need to be familiar with how `with` handles some ambiguous cases in order to use it effectively and safely, `eval` can have some security and performance gotchas. And usually there are other ways to do many of the things you can do with either of them that don't have those pitfalls.
That said, I think the recommendation got out of control -- we have this bad habit of collapsing studies of problems with something into blanket declarations that they're evil.
Here we've got a demo/proof of concept where one of the key constraints going in was code size and using only native facilities. `eval` is saving the developer from writing a parser/expression evaluator, `with` makes it easy to use `eval` while keeping the data in a limited scope. A bigger spreadsheet app would have its own expression evaluator that uses, but using them here makes sense to keep things simple.
They also occasionally make sense in other contexts. Just make sure you really understand the problems involved and have strongly considered other options before you break them out.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#206Earlier quoted context omitted.
That was likely the fear at the time, but what we actually saw was Javascript became popular because it was useful and there wasn't really anything else like it. It became popular, so Microsoft threw in with it too. In order for that to have not happened, it would have had to be so unpopular that Microsoft would decide it wasn't worth adopting, but still popular enough to get Microsoft on board with the general idea.…
that is a weird and complicated take. microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape. simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.
Microsoft's famous "embrace/extend/extinguish" is why they would have followed Netscape in implementing even a scheme-like javascript. They wouldn't have skipped the first two E's just because it was scheme-like instead of java-ish.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#207Awesome! :)
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#208Earlier quoted context omitted.
> it looks like IE8 is finally falling off the radar Some are luckier than others... I suspect one of our major clients (one of the country's largest banks) will be stuck using IE8 and nothing but for the next few years at least. They only moved off IE6 recently due to it falling out of support next April, so there is a chance they'll stick with IE8 until 2019 (the year before it and Windows 7 drop out of extended su…
When I was a contractor at a major bank, the standard was IE6, and movement towards IE8 was in progress (as Win7 was rolling out)... I don't know if they held at IE8 though, as most people I knew there have left, even the FTEs. It was an SPA that drove a lot of adoption/allowance to use Chrome/Firefox, so it may have well gone that direction since leaving.
What's an SPA? (I guess FTE are full-time employees?)
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#209Earlier quoted context omitted.
that is a weird and complicated take. microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape. simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.
Microsoft's famous "embrace/extend/extinguish" is why they would have followed Netscape in implementing even a scheme-like javascript. They wouldn't have skipped the first two E's just because it was scheme-like instead of java-ish.
No, but perhaps there would not have been any pages written for netscape for IE to be compatible with.
Re: A spreadsheet in fewer than 30 lines of JavaScript, no library used
#210next challenge, Word in 30 lines
How about one line?
Notepad