IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: thanks!
Autocasting I can deal with.

"I only mildly like Python"

Yeah, yeah, I knew you'd say that. Would you rather be programming in Perl? I wouldn't. :-)
Regards,

-scott anderson
New Re: thanks!
Yeah, yeah, I knew you'd say that.

Really? I thought the last impression I gave was that I thought Python was really cool....


Would you rather be programming in Perl? I wouldn't. :-)

Been there, don't that. Ugh! :)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Last impression
Basically, the last impression you gave was that you were completely down on any file-based product, and Python particularly because it was good enough to be frustrating that it wasn't as powerful as Smalltalk.
Regards,

-scott anderson
New Ahh....forgot that
Basically, the last impression you gave was that you were completely down on any file-based product,

A year with text editors (including Emacs) and CVS has strengthened my feelings in that direction

Python particularly because it was good enough to be frustrating that it wasn't as powerful as Smalltalk.

Python now frustrates me because I see it as being just more of the same, and making the same mistakes many other languages have made. It's still pretty immature, but as it's trying to grow up, it's doing so in the wrong direction. It's not learning from other's past mistakes.

I use it a lot at home (most of my check balancing/money management is done with a set of Python modules and scripts I put together), but it's not something I see as being ready for big application development yet. (Which, coincidentally, is my job :)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Have you considered telling people?
The Python developers, in particular?

They might be receptive to your ideas.
Regards,

-scott anderson
New Are you kidding?
After the comp.lang.python flame fest over what type the result of "/" shold be and some of the other recent exchanges, the last thing I think I want to do is go suggest that the fundmental thinking that leads to iterators and list comprehnsions is misguided
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Well...
... then don't complain when the thinking doesn't change.
Regards,

-scott anderson
New Excuse me?
Yes I would rather be programming in Perl. OK, I like Perl. I would rather be programming in Python. Oh, you like Python. Well I would rather be coding in VB, PL/SQL, or even go and learn COBOL. All are preferable to JavaScript.

As for the autocasting in JavaScript, trust me. It is a bad mistake.

The basic rule is that variables are untyped, and every function and operator will enforce that by casting arguments between strings and numbers for you. If there are multiple arguments, it will cast depending on what the arguments are. But the operators are also untyped, so you need to guess by some rules. However different operators use different and distinctly incompatible sets of rules for autocasting.

Add in different browser behaviour, and you have a recipe for a nightmare.

I will let you discover the joys of getting event handling to work properly. Suffice it to say that IE uses a bottom-up model (the most specific element gets the even first) while Netscape uses a top-down model (the outermost container gets first shot at the event). The fun quickly progresses from there...

And it isn't just me. The following quote [link|http://www.crynwr.com/cgi-bin/ezmlm-cgi?mss:5054:200008:bccjlknabhieegbnegof|from Kragen Sitaker] may give you a sense of what you are getting into:

I'd rather write bare-metal programs in 8086 machine code in DEBUG.COM. I'd rather edit programs in the Bourne shell on a machine whose only output was a speaker. I'd rather write Perl on my 2.5"x1.5" pager's two-thumb QWERTY keyboard and mail it to myself for remote batch execution.

I have done all of these, in fact.

They are all easier and more fun than writing portable JavaScript code.


Cheers,
Ben
New Well, they're wrong.
I wrote this stuff in a day (complete with unit testing). The application scans a page for updatable elements. It receives updates from a back-end process and automatically updates the page elements with the new data. All the HTML coder needs to know is a few attributes to tag an updatable element with. Everything else is handled. They can choose text, number, or script call as update types.

And it runs perfectly well in both Mozilla and IE. Pre-DOM browsers, yes, there are tons of compatibility issues. Not so with the stuff I'm working with. This type of dynamic application is exactly what the DOM and Javascript were designed for.

I'm not using browser events with this application. And I'm perfectly aware of the different event propagation models (and how you get around those different models). Those issues simply do not come into play with what I am doing.

The alternative was a Java applet and HTTP tunneling, both of which leave much more to be desired for various reasons than does a Javascript solution for this application.

I suspect that you are simply willing to completely disregard my comments without giving me the courtesy of the consideration that an expert developer like myself deserves, as opposed to asking why first.
Regards,

-scott anderson
New Everything has its place
Use the right tool for the job and all that.

There are definitely times when JavaScript is the right tool for the job. It tends to be the right tool more often for simple things and things that only need to be used in tightly controlled environments. It sounds like it is the right tool for your job.

Somehow I am not surprised. As you say, you are very competent.

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.

Which is why I agree with Jay's quote that friends don't let friends program in JavaScript.

Cheers,
Ben
New 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!
New 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
New 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!"

New 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.
New 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
New 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
New Yup, IMO. Oh, and you forgot one: Java.
New 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!"

New 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
     Getting the owning window of an HTMLElement? - (admin) - (35)
         *sigh* - (Fearless Freep) - (21)
             You're a lot of help. ;-) - (admin) - (20)
                 thanks! - (Fearless Freep) - (19)
                     Re: thanks! - (admin) - (18)
                         Re: thanks! - (Fearless Freep) - (5)
                             Last impression - (admin) - (4)
                                 Ahh....forgot that - (Fearless Freep) - (3)
                                     Have you considered telling people? - (admin) - (2)
                                         Are you kidding? - (Fearless Freep) - (1)
                                             Well... - (admin)
                         Excuse me? - (ben_tilly) - (11)
                             Well, they're wrong. - (admin) - (10)
                                 Everything has its place - (ben_tilly) - (9)
                                     Your horse is getting taller by the minute. - (tseliot) - (8)
                                         What is a scripting language? - (ben_tilly) - (7)
                                             Good and bad scripting. - (static) - (2)
                                                 Unix scripting... - (ChrisR) - (1)
                                                     That is partly how it was designed - (ben_tilly)
                                             would scripting languages be anything with an interpreter? - (boxley) - (3)
                                                 Yup, IMO. Oh, and you forgot one: Java. -NT - (CRConrad)
                                                 Not necessarily. - (static)
                                                 I wouldn't draw the line there - (ben_tilly)
         Try '.parent' - (drewk) - (12)
             Nope. - (admin) - (11)
                 Either call from the element itself or pass params - (tseliot) - (1)
                     I passed params. - (admin)
                 My stuff's not in front of me... - (ChrisR) - (8)
                     We own all of the frames. - (admin) - (7)
                         hmmm... - (ChrisR) - (5)
                             No dice. - (admin) - (4)
                                 Non standard - (ChrisR) - (3)
                                     Yes, that seems to work. - (admin) - (2)
                                         Natch - (ChrisR) - (1)
                                             Still some problems with DOM in IE 5.5 - (admin)
                         "All your frame are belong to us"? - (Fearless Freep)

Specifically, they will not save the ship and crew, they will not win a stack of quatloos, and they will especially not get to sleep
95 ms