(I am sure this is fascinating to Perl users...) Shlomi Fish writes: > On Monday 19 Jul 2010 07:23:29 John Redford wrote: > > I am indeed not joking. JavaScript is excellently designed for its target > > purpose. (Those last four words should go without saying, and yet somehow > > they never do.) > > No, it's not.
I suspect you and I have a different idea of what the target purpose of JavaScript is -- and that's quite off-topic. > * I've ran into a need to use either sprintf or date-formatting routines. I > had to resort to using a high-level API that emulated them. I ran into a need to draw dynamic vector graphics. I used an API someone wrote. It worked nicely. I don't see any reason why this or anything else that isn't either necessary or profoundly widely used should be in the core of the JavaScript language. It's stuff people can just get when they need. Just like Perl has CPAN, JavaScript has "code you find on the Internet". It's not as catchy sounding, but it works the same and it's more egalitarian. > * I've been bitten by JavaScript's implicit statements' ending upon newlines > at least once. I never have. I don't think it's the greatest feature ever, but it seems to cause no great harm in practice. I'd say it's about as bad as Python's support for tabs -- it can be weird for some people and lead to bugs they can't see right away, but other people like it a lot. > > One imagines that people who are using JavaScript are managing > > to use it without those things. > > Yes, they are - with great difficulty or while using third party libraries > such as jQuery. What's wrong with third-party code? Why should JavaScript tell people the only way to do things. JavaScript is simply allowing their user community to come up with solutions and use them. There is a lot of lively, active development and many clever ideas. Like Perl used to be. > > Other things on your list are wrong -- > > perhaps one should say they're only true about old versions of JavaScript > > -- or they are purposeful design choices that I'd suggest make sense. > > Like what? Like your comments on closures and for loops. If you look at the features in JavaScript 1.8.1 or even 1.7, you'll find language syntax that addresses these kind of things. > > Like implicit scoping. Which JavaScript shares with Perl and a number of > > other languages. > > Perl with use strict does not have implicit scoping. You need to declare every > variable. And I noticed that the semantics of implicit scoping of JavaScript > are much worse than Ruby's (which I also dislike and has bitten me one more > time) for example. I'd be happy to see "Option Strict" and "Option Explicit" added to JavaScript. Optional extra static checking is dandy, and I tend to turn on all of it that I can in any language that offers it. (I use some of the various lint-like static checkers for JavaScript. If you're not, you might like to give them a try.) But, if it were not-optional, then not having it is the better choice. You don't see Perl making "use strict" mandatory. > > No language is the perfect language for everything. But JavaScript is a > > great scripting language if one wants a language that has plenty of > > implementations, > > Often incompatible and buggy. .... I think you may be talking about browsers here, not JavaScript. Bugs in HTML rendering engines and variations in what events a browser supports aren't actually a part of JavaScript as a language. Those are just APIs. It'd be like saying Perl is incompatible and buggy because some code that works on Unix does not work on Windows. > > no political baggage, no weirdly advocating user > > community, great XML support, and enormous flexibility. It's possible to > > access more functionality from Java or .NET when it's needed. > > How are Java or .NET related to this? Once one is using JavaScript for non-browser scripting, one needs a way to run it. If one uses Rhino, for example, then JavaScript can run in a JRE with as much access to the Java environment as the developer wants to expose. Or one can use JScript in a .NET context and access .NET stuff. Or one could use a JavaScript that lacks those things. JavaScript without a context is like Perl without libc -- it's not going to interact with very much. But you can use it in places where that degree of sandboxing is appropriate -- places where you want a language that won't allow people to create files or open sockets. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
