also is well supported by browsers (note: I am not stating JS is only
good for web programming). The fact that JS is interpreted and has
access to the browser's DOM is fantastic for dynamic, adaptive
behavior during runtime. And sure, JS has funky objects (which don't
have private methods or variables -- which can be good or bad,
depending on how you look at it).
If anyone else is interested, I read through
functional approach (to some extent) most of the language contradicts
good functional style. It's reserved words include a variety of scary
imperative style keywords like break, delete, new, etc. Not to
(and lack of block scoping) is a _bad_ thing considering how JS is
used. Also, if the language is going to differentiate between global
and function scope, it should also adhere to block scoping. This turns
into a lexical scoping problem which kind of forces you to use
closures (although, admittedly you can you 'let' as well). Besides,
I'm all about closures, so I'm not bashing that. I am, however,
suggesting that while JS is a multi-paradigm language, it seems to be
very restrictive with respect to how these paradigms can be utilized.
can find both inaccuracies in my findings, as well as ways to combat
some of these issues... I hope they do because I'd like to know more
about JS... But!
The real argument here (of the paper) was scalability. Currently,
different implementations of JS can be pretty darn fast; Granted. But
the language does not lend itself well to real concurrency. If you try
really hard, you can simulate pseudo threading by using setTimeout. In
this respect, you can perform multiple function executions in what
would seem to be a simultaneous fashion (even though you will not get
language but at this point I don't see it being a hugely popular,
scalable language outside the realm of browsers.
- Michael E. Karpeles
CSSA President & Treasurer
Proud ACM Affiliate