Sophistication in Web Applications? 197
whit537 asks: "Anyone who uses Gmail for 5 minutes can see that it's a pretty dern sophisticated web application. But just how sophisticated? Well, first of all, the UI is composed of no less than nine iframes (try turning off the page styles in Firefox with View > Page Style). But then consider that these iframes are generated and controlled by a 1149 line javascript. This script includes no less than 1001 functions, and 998 of these functions have one- or two-letter names! They're obviously not maintaining this script by hand in that form. So do they write human-readable javascripts and then run them all together, or have they developed some sort of web app UI toolkit in Python? Does Gmail need to be this complex or is the obfuscation a deliberate attempt to prevent reverse-engineering? And are there any other web apps that are this sophisticated?"
MSN's Web Messenger Is Impressive (Score:3, Interesting)
MSN's http://webmessenger.msn.com/ [msn.com] is a web-based MSN client implemented using a combination of HTML and Javascript. The source for the javascript is available here [msn.com]. I was looking into how it worked the other day and tidied the source into a more readable form [bdash.net.nz]. At least MSN had the decency to leave human-readable function names... this fact alone makes the code reasonably understandable.
Re:If they are smart, and they are, (Score:1, Interesting)
So it's funny when you and the original poster opine that it must be written in some "other" language.. JS is actually more sophisticated than, say, Python!
I recently saw some JS code online that added many Ruby-like dynamic methods to the standard JS objects.. pretty amazing I thought.
JS, along with other "embedded" languages like PostScript and Forth are probably way under-appreciated yet are vital for many functions.
why Python if you have JavaScript? (Score:2, Interesting)
developed some sort of web app UI toolkit in Python?
This is why I call Python "Java of the open source world".. so many people think all programming begins and ends in Python.
JavaScript is *already* a sophisticated, object-oriented language. In fact the design of the language is somewhat cleaner than Python. Why do you think they would write it again in Python somehow?
Re:Just quick and easy (Score:4, Interesting)
Kirby
It's all a matter of perception (Score:3, Interesting)
So they get back to the CEO's office, and he uses his PC to dial up Dow Jones News Retrieval service and runs a monster WAIS search.. which used a CM1 that Hillis sold to Dow Jones.
Re:Just quick and easy (Score:3, Interesting)
Aside: I generally use c for my incrementing variables, and foo for my unknown type variables (common in returns in un- or loosely typed languages.
OnTopic: Looking at the code, Google likely has a more verbose code base and runs it through a stripper that minimizes the code and removes comments and excess whitespace. Since they use Python internally, especially in their GMail site, it would be a likely choice for such an app.
While the one and two letter variable names are not at all unmaintainable, I'd imagine that comments and most importantly, indentation are maintained in the original.
--
Evan
Yah, good for Javascript! (Score:3, Interesting)
Dynamic languages are kick ass, I really really like them, but they're for prototyping, not writing maintainable production systems. Static, type checked languages are currently the best way to write maintainable code. In the future we'll have even more formal methods to play with and we can make even more maintainable code.. that doesn't mean we'll leave dynamic languages behind, it just means it will be even more evident that they're not suitable for production systems.
Re:Yah, good for Javascript! (Score:4, Interesting)
This is a myth [artima.com], and has been proven false countless of times, such as by these guys [zope.org], or these guys [gnu.org], or even these guys [php.net], or, God forbid, you may have heard of these guys [slashdot.org].
First, the term "interpreted dynamic language" is vague and misleading. Interpretation has nothing to do with code maintainability. (You can interpret C, and you can compile putatively interpreted languages such as Java [gnu.org] and Python [sourceforge.net] to native code; indeed Java has been natively compiled for years, and the fact that it is just-in-time compilation is irrelevant).
And what does "dynamic" mean? Do you mean a dynamically, as opposed to statically, typed language? Do you mean runtime introspection? Self-modification and metaprogramming? Runtime name resolution? What? I suspect you mean a combination of these. Python, Perl, Ruby, JavaScript, PHP, Haskell, Lisp and OCaml have these features. C++ can be considered a "dynamic" language, as can Java, C#, etc. So why do you claim that these languages are not maintainable?
These newfangled languages are more rapid to develop in than lower-level languages. Maintenance is simpler because the languages are simpler, higher-level and more easily maintained. For example, the absence of a separate compile/link cycle means I can get from changing a source line to testing the source line quicker.
In many cases, reproducing or debugging a bug is simpler in, say, Python than in C, because the infrastructure itself is simpler. Pure Python, for example, does not have memory access violation errors; there's no way your Python code can read or write an invalid pointer, write beyond the end of a buffer and so on; a whole class of pointer errors, most of which have security repercussions, are annihilated by this feature. Similarly, Python uses exceptions, so nobody can forget to check and propagate a function's error return value.
More often than not, errors that surface in these languages are high-level problems, which is good, because those are simpler than the ones involving someone forgetting to call free() on an allocated buffer or accounting for overflow when shifting a bit mask.
The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.
Oh, and JavaScript, a "dynamic language", is being used by Google in a production system, and Google is known to use Python and Ruby in their systems. I suggest you call them up and tell them their languages aren't suitable.
Re:Yah, good for Javascript! (Score:3, Interesting)
- So the fact that there are absolutely no static type checking tools for Javascript has no affect on its maintainability?
Yes. JavaScript is a poor language, but for other reasons than a lack of a static type system.You're obviously trolling. Present us with arguments supporting to the proposition that dynamic typing decreases maintainability, and we'll have a discussion. Until then, you're just spouting FUD.
I have already given ample explanations for my view, but here's a counter-argument to the specific case of typing: Static typing, unless implemented from the bottom up with Ocaml-style type inference (which leads to other interesting problems), adds more metadata to the program, which adds to the amount of text that must be typed, read, digested. Compare:
withThe intent, in both cases, is absolutely clear. The second syntax is simpler, shorter, and more readable.Readability is a huge maintenance consideration. Ease of refactoring is another; if a should be changed to be short, much use of the variable needs to update to accomodate this change -- expressions, function calls, function prototypes and so on. This is why nascent IDEs such as Eclipse focus so much on automatic refactoring, because refactoring is a pain to do in statically-typed languages.
Re:Yah, good for Javascript! (Score:3, Interesting)
That's a good argument for dynamically typed languages which honestly addresses its shortcomings and suggests ways to avoid them. You havn't said anything similar, so I have to assume that you're not aware of the shortcomings of dynamically typed languages and have no idea how to avoid them.
Now that I've actually made a sensible argument for you, I'll indulge myself with a retort. Unit testing is indeed important and when used with a statically typed language even more effective than a dynamically typed language - because at least half of the bulk of the unit tests can be dropped because it is done with a type checker. As more formal methods become available the bulk of unit tests will become even smaller for statically typed languages but will remain the same for dynamically typed languages. This has already happened for languages like Eiffel where verification of object contracts is now automated. These methods are becoming available for Java too.
Re:Yah, good for Javascript! (Score:3, Interesting)
Please. I mentioned unit testing in my first reply, where I wrote:
I also linked to an interview with Guido van Rossum where he talks about this very topic, so if you think I'm ignorant of the issues involved, you must be purposely ignoring what I'm writing. Thanks for trolling again.
Sorry, but interface contracts have very little to do with static type checking.
A pre-condition is typically something like whether a value is within a range, or that an argument is not null, or an array has a certain length, or that an instance is of a certain class at runtime; not whether it's an integer or a string.
Design by contract, being unrelated to static type checking, is therefore a concept that is equally applicable to both statically- and dynamically-typed languages, the main difference being that in a dynamically typed language, the checks may only occur at runtime.
There is nothing preventing dynamically typed languages from doing automated type checking. This [zope.org] and this [python.org] make a good start. The latter is similar to Java 5.0's annotation system.
As for unit tests consisting of type checks, you will probably find that the overlap is larger than you think. Even if a method in Java returns a StringBuffer object, the Java interface can never explain what the contract is: whether it's allowed to return null, whether it always returns a different instance, what that object is supposed to contain.
You will find that in Python, for example, the checks are more or less the same; if the method returned Fnarg instead of the expected object, your test will fail -- unless Fnarg happens to behave like what you wanted, in which case everything is all right. As for input, regardless of the type of language, throwing garbage at functions is always useful; with dynamically typed languages, you might just end up throwing a little more garbage.
Unit tests are supposed to be simple and quick to write. Languages like Python are known to support much more rapid development. Even if you add 20% more checks, you'll still come out on top. Ever worked with lists and maps in Java? They're not first-class objects, so they're a nightmare to manipulate. Such structures are extremely common in tests. (I have been writing Java and Python unit tests every day for four years, so I know where the differences are.)
(As an aside, if in your mention of Eiffel you're referring to design by contract, the concept was invented for Eiffel, so saying it's "now automated" is like saying the Eiffel tower is now made out of steel.)