Science Project Quadruples Surfing Speed - Reportedly
johnp. writes "A computer browser that is said to least quadruple surfing speeds on the Internet has won the top prize at an Irish exhibition for young scientists, it was announced on Saturday. Adnan Osmani, 16, a student at Saint Finian's College in Mullingar, central Ireland spent 18 months writing 780,000 lines of computer code to develop the browser. Known as "XWEBS", the system works with an ordinary Internet connection using a 56K modem on a normal telephone line.
" A number of people had submitted this over the weekend - there's absolutely no hard data that I can find to go along with this, so if you find anything more on it, plz. post below - somehow 1500 lines of code per day, "every media player" built in doesn't ring true for me.
He wants to study computer engineering in Harvard University and eventually set up his own Internet or computer company.
(For people who don't get it, Harvard's CS department, while reasonably good, is not exactly the obvious top pick among CS hotshots.)
I wonder if he will open-source the code?
it is doubtful that he will - according to the article he has applied for a patent on it.
It's curious that there is so few info about Adnan Osmani.
I however found out this thread in the news but, mind you, it's based on the same story...
They bet that if it's possible, he may have either implemented some quick prefetch and/or pre-formatting subroutine...
Trolling using another account since 2005.
If it does require a server side piece, it's not a web browser, per se; but as a general question, is it worthwhile to look into "compressed" web pages, e.g., foo.html.zlib?
This already exists, look for example at mod_gzip for Apache. This will compress pages before transmitting if the browser claims to support it. Mozilla does, I believe IE does too.
Its probably not fair to characterize Sarah Flannery's work as having had, "no solid documentation." As this page at Cryptome points out, Sarah's work did not "revolutionize cryptography" because several mathematicians -- including Sarah herself -- identified a "definitive attack" on the technique described in her winning paper (which was an application of the Cayley-Purser algorithm). Her book remains a good read, especially for young women, and I don't think anyone believes that the math in her original paper is anything less than exceptional for a 15-year-old.
Bullshit. Get your facts straight before you malign someone. Sarah Flannery
She used Mathematica, so the Wolfram website has review of the book.
Here's a quote from Bruce Schneier in his 15 Dec 99 newsletter .
All of this was easily found with a Google search that garned 24,000 hits.
One possible explaination for the LoC count may be that he's using Borland and trusting it's "count". At my first real job, we used Borland and I made a realtively complex program over the course of 18 months (coincidentally enough). The line count was over 1.5 million, but the reality was that it wasn't that long, Borland was counting lines processed, which included the header files, and the OWL and windows headers could add a lot to each module (of which there were over 100, since I was big on modularization).
I never really knew the true line count. I just remember the Borland one because I used to often do a global compile any time I wanted a half hour break ("Oh, the systems acting funny. Better do a global compile to make sure it's not a dependancy problem." If my boss came by and I wasn't there, he'd see the compile running on the screen).
-no broken link
well,
:-)
....
... e.g. using auto_ptr templates in C++ instead of manual exception management and manual allocation and deallocation inside of a function lets you "work" much faster and yields more maintaneable code. More readable, less to think about and faster ongoing to the next feature.
when I had "software engineering" in my computer science courses, we got this figures for LOC per say:
Application programs: 25 - 100
Service programs: 5 - 25
System programs: 1
Application programs are things like an editor (albeit some editors are rather complex), service programs are things like cc and ld or asm (albeit some of them are not "that" complex) system programs are stuff like the kernal itself or, dynamic link loaders, device drivers etc.
Well,
we all know that LOC is not a defined "value" but people working a lot with that "measure" just define it
E.g. if you work with COCOMO or with PSP(personal software process) the typical LOC is defined as a single definition, a single expression(some even say every part of an expression), an argument to a function call, every include, every define and so on:
fprintf(stderr, "this is an error number: %ld", errnum);
That would be 4 LOC, one LOC for the "statement" and 3 for the 3 arguments. Consider you can make an error/bug in every argument or 'misstype' fprintf for fscanf
LOCs do not realy get interesting in comparing hero programmers (10 to 20 times more effective) with standard programmers, but by comparing programming languages!!!
The VERY INTERESTING point about LOCs is that the noted rules of thumb above are independend from programming languages!!!
A programmer writing lets say 12 LOC per day C also writes ~ 12 LOC per day in assembler, in LISP in PERL or what ever language is appointed for the project.
So: the more expressive and the more abstract a language is the more "algorithm" or "computation" is defined in the lines of code.
In other words: 10 lines of C are far more calculation than 10 lines of assembler, while 10 lines of LISP, SQL or Prolog are even more than C.
Bottom line: the number of statements the average programmer can write depends far more on the problem domain than on the language choosen!
Well, the productivity of the so called hero programmer is in general not in lines of code, but in "abstractions" he implemetns. Or in number of features he implements. And that is often acomplished by choosing the right language constructs(not by writing more lines)
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.