Your horse is getting taller by the minute.

Post #6,599 by tseliot 8/24/01 11:45:13 AM Reply	Your horse is getting taller by the minute. But even so for general purpose programming (particularly, though not only, in a mixed environment) JavaScript reaches the end of its rope well before a decent programmer reaches the end of their ability to tell it things it should be able to do. For instance in your application if you are running JavaScript simultaneously from within multiple frames (you did mention frames) and they interact, you will have race conditions and aperiodic crashes. There is no support in the language for getting around these races. To me that makes JavaScript a seriously broken tool. Sorry to descend into analogy, here, but that's like saying the tire iron is a seriously broken tool because you can't manufacture an entire Audi out of it. We are in the scripting forum, are we not? Nobody's talking about using Javascript for "general purpose programming" (which appears to be your euphemism for Big Projects) except you. JS is a small, client-side tool for use in web-based applications, and in that environment, has no real substitute. Nobody is trying to tell you to build your business on it, and certainly not on it alone. Which is why I agree with Jay's quote that friends don't let friends program in JavaScript. Uhhh... yeah. Scott, you're my friend, and you have my permission to continue using Javascript where needed. Oh, and good to have you back, Ben. Don't recall if I've had a chance to say that yet or not. :) That's her, officer! That's the woman that programmed me for evil!
Post #6,621 by ben_tilly 8/24/01 1:31:34 PM Reply	What is a scripting language? To me a scripting language is a language which is explicitly intended to make it easy to put together small but very useful programs. For instance in Perl: perl -MLWP::Simple -e 'getprint("[link\|http://z.iwethey.org/")'\|http://z.iwethey.org/")'] is a complete working program that does something useful. On the surface this has absolutely nothing to do with what we think of as "real programming". However if you look at popular scripting language after popular scripting language, you will find some sort of support for real programming techniques in most of the successful ones. Why? Well quite simple, really. We live in a world where you need complex interactions with the outside world for common tasks. To successfully script those common tasks you need access to a convenient interface which allows you to simply say what you want done. Those interfaces can be built into the language, built into additional libraries written in the language, or can be interfaced from other languages. (That order is in what I believe to be descending order of convenience to the user.) Unfortunately a language can reasonably contain only so much functionality. Certainly far less than what users want, and it is guaranteed to omit things that will be considered important in a few years. Therefore successful scripting languages emphasize extensibility. Either the ability to extend the language from within the language, or from external interfaces. (Or both.) For instance the above program is only simple because I loaded an external library that itself loaded a series of libraries which did a lot of work on my behalf. However JavaScript has a poor story to tell on extensibility either from within or outside of the language. If you want to do what it does on the client side, you have no real choice but to use it. But as far as scripting languages go, it is not very good. Some of that is not its fault. It is inherent in the problems of a client-side language. However some of it could be done much better. My theory as to the real problem is simply that you don't get client-side choice. If you had many competing client-side languages, then the best would win and ones with some of the horrible mistakes that JavaScript makes would go away. But the barriers to becoming a widely used client-side language are so high that JavaScript is likely to remain widely used for the indefinite future. No matter what its faults are. Cheers, Ben
Post #6,757 by static 8/27/01 1:54:23 AM Reply	Good and bad scripting. I think we - as in, us in IWETHEY - are expecting perhaps a little too much from the term "scripting language". DOS Batch files are a scripting language. Not very powerful, true, but they script the running of several programs one after the other, with some logic direction. WordBASIC (as used in Word 2) is a scripting language. Not spectacular, I'll admit, but it easily replaces long key sequences and has some decent if not fantastic logic control. Perl, OTOH, is a scripting language on steroids. Is there anything it can't do? Of course, that is it's attraction. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #6,774 by ChrisR 8/27/01 9:55:57 AM Reply	Unix scripting... To my way of thinking, Perl is an amalgamation of scripting languages - shell, awk, grep, and sed come to mind, with a lot of C syntax thrown in for good measure. If you use Perl for a number of other things, you don't have to drop into these lower level scripting languages, though it certainly helps to be fluent in them as well.
Post #7,586 by ben_tilly 9/3/01 7:25:46 PM Reply	That is partly how it was designed It has been said that, Perl is the Cliff-notes of Unix. Intentionally so. What Larry Wall did is take a lot of useful things from Unix and tried to put them into one package, with somewhat tighter integration. (For instance Unix pipelines are list-oriented with lists being designated as lines. Perl is list-oriented with lists being scalars.) Larry Wall will be the first to tell you that he isn't very original. But he is a great integrator. And personally I would say that whether you like or dislike Perl, you have to admit that he changed the face of scripting languages... Cheers, Ben
Post #7,486 by boxley 9/2/01 12:29:41 AM Reply	would scripting languages be anything with an interpreter? as opposed to a standalone compiled executable? If a file may be run natively it is a program. If a file must call an interpreter it is a script. Scripting languages Perl Basic xbase C# compiled programs c++ pascal forth assembler not to say simplicity and power as well as ease of use is granted to either class thanx, bill Our bureaucracy and our laws have turned the world into a clean, safe work camp. We are raising a nation of slaves. Chuck Palahniuk
Post #7,514 by CRConrad 9/2/01 8:02:48 PM Reply	Yup, IMO. Oh, and you forgot one: Java.
Post #7,552 by static 9/3/01 2:19:02 AM Reply	Not necessarily. Most BASIC interpreters actually execute a sort of p-code version of the program. Even Visual BASIC did that until quite recently. Those found in home computers of the '80s actually wrote a tokenised version into memory, which it translated as you entered lines. OTOH, BASIC compilers have been around a long time, too. So. In fact, the line is blurry: Perl is translated into an internal p-code version before it executes it. This is much like what happens with virtual machine languages like Java and Icon, but without the explicit step of "compiling" (Icon's "compiler" is actually called a translator, incidentally). Interestingly, SNOBOL functions like Perl, with an implicit translation prior to execution. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #7,585 by ben_tilly 9/3/01 7:18:31 PM Reply	I wouldn't draw the line there And even if you did you would have various cases on the boundary. For instance Forth and Pascal both have had incarnations as interpreted languages. Python and Lisp are examples of languages which are often run both as interpreted languages and as compiled programs. As I said, I would draw the line at the point that a scripting language is one which has as a significant design consideration that it should be possible to write useful programs with very little code. Of course that doesn't make that the only design consideration for the language, and it doesn't mean that such languages are only useful for short programs... Cheers, Ben

Welcome to IWETHEY!