Slashdot Mirror
Sophistication in Web Applications?
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?"
I don't believe that the naming of the functions and variables is simply an effort to obfuscate the code. There is that, of course, but the main reason is probably to save money on bandwidth. When you have millions of people hitting your servers you can scrape quite a few bucks by removing white space and reducing the size of your files the way they have.
I think he may have derived "in Python" from the fact that Google has been hiring many Python programmers in the past couple years.
... just like the rest of this article.
However, it was completely uncalled for speculation that had no place in a Slashdot article.
I'm with you, "huh?"
Random and weird software I've written.
1200 lines of Javascript might seem like an enormous amount to a dreamweaver monkey, but it's hardly any code for anyone who does real programming*. Check out the scripts for Outlook Web Access for example. Or any other intranet/portal type application.
(*Well, many 'real programmers' are loath to do rich client stuff in JS, perferring their server side frameworks instead. But once you get the hang of it, it's pretty nice.)
MSN's http://webmessenger.msn.com/ is a web-based MSN client implemented using a combination of HTML and Javascript. The source for the javascript is available here. I was looking into how it worked the other day and tidied the source into a more readable form. At least MSN had the decency to leave human-readable function names... this fact alone makes the code reasonably understandable.
"pretty clever little language" is the understatement of the year. The entire UI of the browser that I am using now is done in javascript.
Both Perl and Javascript can be maintainable if the programmer designs their code with that goal in mind. Besides, Gmail has slightly more than 1000 lines of code. That really isn't really a maintenance nightmare.
Java is an object oriented language, but I could certainly write Java code that would be a major headache to maintain if I chose to do so. I think most maintenance problems come from poor coding habits, and not the language its self.
Actually, if you browse around Google and Gmail, you'll find tons of links like this one - the file has a .py extension.
Google writes A LOT in Javascript. It would not surprise me, although I have no evidence of this, if they wrote the code in their choice editor and then ran a python app that condensed the code to remove space, renamed the functions, and replaced all function references. At 1000+ functions, if the function names had just 5 letters each (not much if you're not being terse), that would be an extra 3000 characters (3k) PER PAGE LOAD. Multiply that times thousands (tens of thousands after general release?), and you'll see A LOT of extra bandwidth.
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?
Kirby
For the number of times "ii" occurs in english you could save yourself a character, right there.
Now, I'm off for a bit of skiing...
People can be fooled into thinking things are sophisticated apps when they're really not. I'm reminded of a famous anecdote from Danny Hillis. He was trying to sell his Connection Machine with WAIS software to a CEO for enterprise-level data mining. He gave the CEO a demo at his shop, the CM1 did its thing, and the CEO was totally unimpressed, and said, "hell, my IBM PC back at the office can do that!" Hillis couldn't believe a 286 could do something that requires a CM1 supercomputer, so he asked the CEO to take him back to his office and show him.
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.
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
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
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.
How we know is more important than what we know.
that would be an extra 3000 characters (3k) PER PAGE LOAD
Well, that js file would be cached by the browser, hopefully, not reloaded with every single page load.
$8.95/mo web hosting
When you sign up to be a Python Programmer you have to promise to evangelize rabidly. At least that's been my experience. Evangelism must include suggesting that python is the best language for every job, trashing every other scripting language, and suggesting that Python is what makes the Holy Grail work. ...and to mod-down any Slashdot post that doesn't beatify Python, I'm sure. There goes some karma...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
*correction - a water skiing resort... in hawaii... working on an ascii front end for a diiodide metering device... Just a though: /usr/share/dict $ grep -ic ii words
419
"Sanity is not statistical", George Orwell, "1984"
In regular C, for a function, it's actually highly useful, and extremely desirable. Go look in any extremely large body of C code. You'll find out just how desireable C static functions are. They are used all the time inside of the Linux kernel. They guarantee that the linker won't make that symbol available externally. Which is great for avoiding two different functions with the same symbol.
In regular C, using static on a global variable also makes it have no external linkage. It also moves where the memory is actually set aside. Which changes when it gets initialized, and how large your executables are. I believe it's also a very good way to ensure your variables are safe to use in signal handler context. This is common go look at the Linux kernel. Happens all the time. Highly useful application of static.
In regular C, using static on a variable in function scope, can be useful, if it is also a constant. In that case, you can move the space off the stack and into the BSS section (at least under UNIX, I forget the equivilent under a Win32 platform). This again is used all the time in the Linux kernel. It shrinks the stack usage and saves space. As I recall, you want to declare all strings that are constants as:
static const char foo[] = "foobar";
It saves space in the kernel. I forget exactly why it does right off hand, but it has to do with the assembly that GCC outputs. I might have that wrong, you might want to do "*foo" instead of "foo[]", but you get the idea.
Now, in regular C using static on a variable in function scope to store state between function calls is an excellent way to introduce a race condition. So your blanket statement that "static is evil" is blantantly wrong. Whoever or where ever you learned it from was mimicing what they'd heard before without any understanding. Next you'll be telling me there's no good use of "goto's" either. Which isn't the case, they are few and far between, but they do exist. I've never come across one, but I am aware of when they would be useful. I could make use of them, but generally performance, cache coherency, and "the fast path" aren't things I generally have to worry about. Those are the types of problems we just throw more hardware at and keep the code highly maintainable.
I learned about a lot of thinks from my old boss, but the "iii" was one of the truely unique things, I've never seen anywhere else. Any good text on C programming will explain what I just did. The small useful things that you just deal with all the time because you never stop to think of a better solution. Paul didn't have too many of those. He recongized anytime something was difficult, and pondered the problem until it was easy. Just like, he knew when static was a good idea. Although I actually picked that up at school, during the explaination of Ada. You can do something named modules in Ada, that you can somewhat duplicate in C with static and separate translations units.
The truly most useful thing Paul ever taught me was just assume all of your code leaks memory. Assume your code will segfault because there is a bug in it. Assume you'll get crappy data that will lead to pathelogical cases. Design your code so that as much as possible that doesn't make any difference in terms of your ability to process data that doesn't cause a memory leak, a segfault, or isn't malformed. Never get stuck when there is more data to try. If some data elements blow up your code. Timestamp when you tried them and don't retry them for a while so you can work on other data. Any time you are doing batch processing, you should always have a parent that is deathly simple that will spawn children that do the real work.