Note: This entry has been restored from old archives.
“because it’s not compiled, it’s also very quick” [1]
It’s a different definition of quick of course, but somehow I begin to feel disconnected and trolling mode wells up from the darkness within.
But… even in that sense, is it really as quick as we think it is? In my experience it certainly makes it quicker to discover new and interesting types of bugs.
The quote relates to Ruby, but really, be it Ruby, Perl, or Python it seems much the same.
[1] I’ve quoted from the 3rd page of an article there. I’m still not quite sure why these sites bother to separate their articles into “pages.” Even SMH used to be one-page-per-article before this pagination fad caught on.
With the SMH site you can append ?page=fullpage to their URLs to get rid of the pagination, which is better than nothing. Sometimes they even include the link at the top of the story.
High level scripting languages are “quicker” in my book. I can certainly get the code to do some task done faster in python that I can in C. It has absolutely nothing to do with to compile or not to compile though. If you had to compile python code before you ran it, it wouldn’t change much of anything
However, as the code gets larger, the difference gets smaller. Because writing the code (and even reading the code) begins to be outweighed by managing the code in terms of time spent. Though I guess high level languages still win there, since it takes longer for the code base to get that large – I’m thinking about similar code base size projects – which is probably incorrect (should be similar functionality size projects).
Of course having your typos cause the compile to fail is about 47 order of magnitude better than having them crash the code when that piece actually executed (and of course that case won’t have happened in your tests…) or worse merrily run without notiving a problem but giving completely invalid results.
Then again managing memory is retarded to do by hand 🙂
C++ could have been a nice middle ground, but the STL and templates in general took a wrong turn a long time ago.
LISP is of course the way the truth and the light, but good luck finding a new programmer when you need one…
Yeah, I believe they probably are “quicker.” I just wonder about it sometimes, usually when I’m debugging something!
I have one very good experience using Python, writing a rather large application. I’m certain it would have taken a lot longer to achieve the same functionality using C++ (and robustness, AFAIK it is used daily and there has never been any issues … AFAIK;) To add to this, half way through the spec changed … Windows support became essential. This was incredibly easy, Python/Perl/etc seem to be more amenable to cross-platform coding than C/C++ (regardless of “standard”) and Java. (The Python “port” was trivial, the only issue being an easily solvable kerfuffle regarding SIGALERT.)
LISP : still trying to make time to play with it some more. So far all I’ve managed is some pretty trivial numerical stuff. Some day I have to re-write the pile of bloxsom shite that drives this site, maybe Lisp? Paul Graham says it is brilliant for websites, after all. Then again, maybe I should go with Arc in that case.
SMH : yeah, but the single-page mode isn’t the default. I guess there’s some Firefox plugin I could use to regex-munge URLs though, to make it my personal default. I assume the pagination is mostly in the name of advertising exposure… it could be to save my pointer from mouse-wheel RSI I guess, somehow I doubt it though.