Well, the UI is the most resource intensive aspect Linux from my perspective. Conversely, the java VMs on android are probably it's greatest resource hog. Windows and MAC have more "optimized" UIs, whereas most things on Linux UI are X-based which means most communication is serialized through a single socket and much information is stored redundantly in the app and the X-server. Hell, in recent versions of Fedora I have a problem where my X-server grows to over a gig of RAM even when all windows have been closed. I hate the fact that I have to log-out/in-again because of mem-leaks in either X or gnome (can't determine which). Ironically, I still prefer gnome over Mac/Windows UIs in terms of it's expressiveness / adaptability to my needs.
So it makes sense to provide OS hooks for an alternate UI mode.. Hell there's dedicated VGA mode for games in existing Linux. Gnome/KDE are not light-weight (though X can be), and I can't imagine how you could retool them to be. Much less how you could to this in a way that supports existing KDE/Gnome/X apps.
Remember, we're talking the slowest possible hardware above cell-phone-grade that we're talking about here. Big screen and keyboard, but essentially a cell-phone/PDA on the backend. I wouldn't be surprised if the browser is required to be full screen like on a cell.
Further, there is a serious argument to be made about low-performance devices and the lack of desire to store sensitive / loosable information on them. Viruses + hardware failure + hardware upgrade means losing your data. While some people avidly setup backup strategies, it's applied with lesser diligence to lower-end devices. And if you're buying on the cheap, than backup solutions cost extra thereby defeating the point. Why buy a $100 netbook then have to buy a $90 external backup hard drive?
I'm not saying this isn't valid, I'm saying that there are massive groups of people that are affected by quality-control issues and migration strategies of software vendors including MS, and google is allegedly attempting to obviate that aspect entirely by making low-cost devices 100% online.
I do see a valid use-case.. 3'rd world, poor US citizens, virtually every high school/elementary school.
Of course google is merely trying to promote it's online dominance and we should take pause. But other than the OS, I'm not sure that this ties your experience to google (though maybe their search engine/user-profile - but anti-trust will eventually kick in).
Who said backup? People see what they want to see.
BackupPC server: Linux SW RAID-1 (3 way, leaving a DVD slot) mitigates bad-blocks.. On first smart error, throw the $30 disk out and plop in a new one. Desktop: Linux SW RAID-1 (2-way).
External USB/NAS for the BackupPC server.
Judicious manual use of subversion for local configuration files in read-only checkpoint mode (so history never changes and thus is safe/efficient to backup). This is slightly redundant with BackupPC's version-checkpoints, but allows a compact infinite history, and visual deltas.
Occasional off-site rotation. (possibly using Amazon storage).
For servers, at my work, we do almost the same thing, but use hot-swappable hardware raid controllers with RAID-01, and we use LVS snapshotting for consistency (every try to rsync actively changing data?) and for apps that support it, explicit dump operations (like mysqldump) to produce wholly consistent point-in-time backups. For our light-but-real-time servers, we ALSO use drbd (block-level network replication) along with heart-beat.
Frankly, I'm rather surprised by the backlash against RAID here.
"If the application was purely CPU bound, and Y wasn't giving me 35% more than X, I'd complain."
Huh? Why should a specific APP be expected to achieve that max theoretical performance increase that a contrived benchmark (specInt, etc) rates? While this class of bench marks is based on 'real world apps', nobody uses those apps anymore.
You can write two 'CPU bound' apps that have completely different branch-patterns and memory-patterns. One with great instruction-sequentially and mem-locality (and thus deep-pipeline utilization and highly cacheable even though it exceeds the cache size) and one which makes effectively random walks through memory with contingent random code-jumps (such that DRAM banks are constantly powered up and down). You'll totally trash the memory performance and thus your memory bus bandwidth is bumpkiss.
So if you are currently achieving say 60% max-theoretical throughput on CPU-1, then what the author is suggesting is that CPU-2 should achieve 135% * (60% * CPU-1). But the design decisions of the new CPU might be such that the particular code-flow of the target app are actually WORSE (i.e. a longer pipeline visa v. the Pentium 4). The issue might be more subtle, such as fooling the branch-predictor logic (which is complex). Or it could be that the data-dependent random memory walks are such that the parallel memory channels CAN'T be utilized effectively. So BW and parallel chips don't make up for fundamentally rate-limited random-access latency.
The point is, ALWAYS sample the new hardware and make mass purchasing choices based on your personal cost-benefit analysis.. Bitching to the vendor is unfruitful - choose alternate purchasing strategies.
"with two different genes in the same place, the non-broken one can make up for the mutated one, but with inbreeding there's no redundancy."
Speaking from from high-school biology decades ago.. There were dominant and recessive genes (I'll call D and R) - neither necessarily broken. DD, DR, RD utilize the D gene and only RR activates the recessive. Natural selection is supposedly such that if gene-R would not be able to survive in a given environment, RR's would die out, BUT they'd still be passed in the gene pool such that it's possible that an RR will occur on occasion.. These should be still-births or otherwise die out before reproducing. From a survival perspective, this allows R to not become extinct and thus if R ever did become necessary, some fraction of the population (that hadn't died of RR yet) would now BECOME the dominant genetic code.
In this environment reversal, I didn't understand whether R could become dominant or whether D would necessarily have to become extinct in the population (which would seem to defeat the point).
But in terms of in-breeding, you have a much higher probability of getting a greater number of RR combinations for a given person (of your 25k some odd genes), since you have far less variation.
But here's what always struck me, and I never fully got this impression from the scientific community.. Lets say all the above are true. Then a small community becomes isolated, such that it's forced, ultimately to inbreed (there have been many great-dyings in mans history, to say nothing of earth's history). Your first generation will have a LOT of RR's, and they'll die out... BUT if you have a sufficient number of DD's, then you'll actually produce super-healthy children. Presumably the entire community have a better part of the complete suite of valid D's, just mixed in with the occasional R.. This massive in-bread children-making process is going to have a lot of death, but in the end, a cleansed population.
Since high school, I've been led to believe this is a dramatic over-simplification of genes. So the model probably breaks down, except to say that statistically, in-breads have greater ratios of down-syndrome and that man has survived mass population decreases.
Well, as best I can understand it (listening to a lot of talk-radio - so don't have hard references, sorry). The old testament had dozens prophecies. One of which mentioned a young-woman giving birth to a bla bla in Hebrew. The translation CAN be interpreted as a virgin birth (as the wording is sufficiently vague). So when people tried to retroactively apply all the prophecies to Jesus (ultimately recorded in Greek), they flat out labeled the Mary birth as virginous. So it's harder to claim the Greek is mistranslated, BUT, it's part of a larger argument that little if any prophesy was actually fulfilled (Jews weren't freed, etc), and are thus ultimately questionable embellishments that the Nicea council chose to go with some - 300 years after the events in question - based on recordings some 60 to 110 years post-facto.
This, of course, begs the issue of whether prophesies are relevant to begin with (since much of the Nicea justification was the fulfillment of Prophecy - that's what's echoed in Catholic church).. Consider our modern obsession with Nostradamus every season (or even Deja-Vu). The argument I would make is that either prophesies don't exist - they are man's struggle with statistical behavior. Or they DO exist but in divinely fucked-up ways. Such that an Edgar Casey / Nostradamus are non-religiously-important, yet Mohammud/old-testiment (and loosely speaking Jesus) IS. Islam of course conveniently says Mohammud was the last one.
To me, accepting prophesy opens a can of worms such that the world makes tremendously less sense and is more scarry than rejecting it. You've got Angry daemons who lie to you through dreams competing with benevolent Angles whispering secrets - you've got Christian prophesies that there will be great deceivers, you've got all Christian/Islamic morality tangled with power-hungry figure-heads that history proves time and again were ultimately immoral. So it's impossible to be religious and a believer and have any assurance that you're acting morally (outside of the incredibly obvious moree' of don't fuck with people). The simple recognition that alpha-males naturally will deceive as necessary to achieve power, and that people are susceptible to superstition is a much simpler explanation of history.
Now now.. Religion is incredibly important. It's just an anachronism these days that people are unwilling to accept. Just like the horse and buggy was critically useful at one point in time.
Consider that you live along the Nile and you have to maintain a peaceful order of how people utilize this scarce but incredibly life-given resource. You could just kill people that didn't do what you said, but eventually people would find ways of sneaking around the law.. So you invent a Santa-Clause - someone that knows when you've been naughty. Even if it doesn't spook you, it might spook the police-officer who's in charge of watching out for the scarce resource. Spook him enough that he can't be bought off. Sure some fraction of police can still be bought off, but the Santa-Clause thing is sure to give you a greater fraction of adherents.
It's wasn't even entirely artificial.. The world of course had it's mystical properties to the simpler man - superstition was already there.. religion was just the socialization of these mystical properties.
I have friends/family in atheistic countries, and the thing that struck me most about them is how superstitious they are (given their high degree of education). Borderline voodoo rituals go on there. I don't know how much of that relates to the Zoroastrian regional influence or how much the human need to personify statistically rare occurrences are. Growing up in a Catholic religion, we of course laughed at all things superstitious (ignoring the irony of our own culture), and so my switch away from Catholicism was more-or-less clean. But if you didn't have the transition from unquestioned-faith to faithless, I suspect you might be susceptible to random unsubstantiated explanations. Oh well, I'll find out when my kids grow up.:/
It was common practice to free people from the cross while still alive. So given the deceitful nature of other portions of the bible, I'd say there's a greater likelihood that either the Jesus character was more a legend-status after his big public speeches (and all subsequently 'documented' events are suspect, albeit 60 to 110 years later), or that he indeed was partially alive after being pulled down.
Both explanations are far more plausible than the poorly described and seemingly nonsequiter resurrection. Nonsequiter because it makes no sense for him to 'die for our sins' when death was merely symbolic because he had the 'magic' ability to retake human form again. Where's the sacrifice? Remember, the story isn't that God forgave both Man and Jesus then gave Jesus his body back (which at least would make sense from a story perspective).. It was JESUS who ressurected his own damn self because he WAS GOD. Even when I was a devout catholic this part made no sense. That's up there with God inventing the prism effect out of the blue one day to prove to Noah that he wouldn't toast the earth again. THINK FOR YOURSELF PEOPLE.
Silly discussion.. Lazarus and Jesus didn't die. Simulated 'rebirth' was a symbolic pagan ritual popular in the day. This was known even before the recent discovery of 'lost' testaments - which more-or-less proved the mis-historical-representation when Jesus had a conversation with Lazarus before 'resurrecting' him.
"It just consumes way too much memory, and starts damn slow."
Sigh. I've said this 100 times.. server apps (as relevant to this COBOL discussion) don't have startup time. They are up for months at at time (years even). Please distinguish between client-side apps and server-side apps.. As java-programming only exists in client-side-apps these days as server-interfaces (for fast-to-build, yet bug-free coding of mission-critical-apps) and cell-phone-apps (for hardware-portability). For this class of client-side apps, yes you can bitch about memory usage and startup time. Though hopefully memory usage shouldn't exceed 150Meg (a typical firefox executable). Server-apps, on the other hand have completely different requirements.
A 'server' that runs java costs between $900 to $10,000. What is the cost of 2Gig of memory? $100? $200? Give me a break. Further, I usually recommend only using the 32bit JVM and thus <= 2Gig of JVM memory (typically caping out at 1Gig). Thus the worst stop-the-world GC-collection time is on the order of 1 second. This pause sacrifice gives you better overall throughput. There are server-app types that require 16, 32, 64 or 128Gig of RAM however, and thus you need the 64bit JVM (64bit pointers increase mem-overhead and cache-coherence) and can't risk the nearly-a-minute pause-times, so you need incremental collectors (with an additional 15% performance loss). But for this, I usually say that such large memory foot-prints are best handled by consolidated network-APIs. This allows you to cluster the apps on smaller, cheaper hardware, and then have a pair of larger-memory hardware on the back-end. But at this point, is the back-end really any different than a traditional large-mem database (such as mysql-INNODB or mysql-cluster/NDB or memcached)?
And as for:
"here's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good..."
If you're writing server-code (for targeted $10k hardware clusters), I should hope you're not paying somebody straight out of high-school. Or at least have coding-standard and code-reviews with senior staff.
Otherwise, code to google-apps and run a castraded java-api that doesn't really let you waste resources and doesn't have startup-time issues. Actually, it's a pretty good segway for server-freshmen.
JIT code is slow? Or JITing the code is slow? When I run bench-marks, the average-benchark speed continually gets faster and faster as I increase the number of iterations. This is because the JIT continuously re-assesses basic-blocks to determine if coallesing is worth the expense. This means: A) code is NOT JIT'd at first, even with -server.. ONLY after a min-number of passes (why JIT initializtion code that'll never run a second time?) B) book-keeping to determine what to JIT and what not to JIT adds extra overhead for rarely used code C) Even JIT'd code is continuously evaluated to determine if larger execution-flow-patterns are possible.. So the same code might be JIT'd 50 times, each time being aggregated into larger bundles of contiguous raw assembly
Thus, for short-lived applications, the JIT only provides marginal benefit if not a detriment (which is why the google android's JVM does ZERO JIT, and instead uses an alternate byte-code which is more efficient to cold-start).
But, for servers (web-servers and mainframe code which will batch process all night long), you're talking about relatively small chunks of code (out of the overall loaded library) that are highly reused. It's entirely possible that an entire web-page can be inlined into a single chunk of assembly (though it's a stretch). Not even PHP can do this (at present).
Basically typical code is complex because of optional flow-paths (if-statements, etc).. But in highly repetitive batch/server processing, there are a handful of paths which make up maybe 99% of execution, and thus can be rewritten in a way that in C would be horrendous (though certainly possible).
Doing code-analysis to prove that an array index will never be out of bounds is expensive.. But once done, you can remove a lot implicit assembly-code. So general-purpose 3'rd party code can be almost fully optimized away. You get the best of both worlds.. High-degree of defensive coding + optimized execution. The cost is the ramp-up-time (and an immodest but reasonable memory foot-print).
For single-app-servers, throwing 2 gig of RAM is NOTHING ($100 v.s. $5,000 ???), so I'm frustrated when I hear people bitch about memory consumption.. Memory use is bounded, if not, then you have a coded memory-leak and that's not the JVM's fault (usually due to misconfigured-as-unlimited in-mem caching - usually a disk-spill-over-caches that unknowingly (to the coder) retains headers in-mem).
C# might be better than java, but Java is an order of magnitude better than Cobol. And they weren't building an 'open-source' MS + C# stack. And Linux + mono stack is no where near the performance capability of MS C# or SUN/IBM Java. Consider that 90% of the java-byte-code is rewritten as highly optimized assembly in a server environment (often better than hand tuned C/C++). You're assessment of java is clearly wrong.
And as to the basic premise of this thread that java is a lesser programming environment - speaking from someone that favored C over C++ for 10 years, I loath going back to open-source C projects v.s. Java projects. A good editor makes reverse engineering Java-code take minutes instead of hours for C. The static-typing nature of a Java development environment means nearly 90% guarantees that code does what code means.. no side-effects, no package/name-space trickery. An editor can be nearly 90% correct in saying "here are all the code points that utilize this class/method/field". So I can reverse engineer how the code is used. I can walk through code, not worrying WHICH of 50 #ifdef's/alternate-.o files the compiled code is going to actually need - so 'drill-down-to-method' is concise. The remaining 10% is due to reflective/aspect-oriented code (sadly now taking over in the Java space). Thankfully much of the AOP is compartmentalized such that editors have a very good idea of where the use-points and jump-points should be.
If you don't believe me, TRY and read through all the lines of apache or mysql-INNODB, and compare that to running through the lines of java-tomcat or java-hsqldb. And tomcat is FASTER than core apache for static files (though of course there are plugins that do various things in a specialized way faster).
Reading code is VERY much a function of seeing both the bigger picture and the details from the same vantage point. The greater a developers perspective into code, the greater his ability to assess the correctness and more importantly the extensibility of code.
C-code, in general is not extensible. It's tool-box based. C++ is better, but most methods are not declared virtual, so they're essentially static c-functions for the purposes of a 3'rd party. Even only decent java code is fully extensible - especially when written with interfaces + injection-oriented design (the latter only being a recent trend). Thus even your toolboxes can be used in ways the originators never imagined possible. The reason one might not declare methods as virtual in C++ are performance, but thanks to Java JIT, all functions are treated as 'final' in the end product - all virtual methods are effectively inlined where practical. Thus there' no reason to artificially castrate your java code for the performance Gods.
And don't forget, nobody runs COBOL in as a web-plugin.
The failure of American pupils is probably not due to the way the subject is taught, but rather because they don't feel the pressure to excel like students in other cultures.
Huh? Getting into college isn't an extremely pressing/taxing/competitive ordeal?
I'll tell you why US students are degrading in test-worthy performance: Grade-inflation forced down the throats of schools by bitchy parents who can't believe their kid got a C when in prior years they'd gotten an A (most likely due to grade-inflation having to slowly work it's way up and through college). This does a tremendous disservice to the children, as they are less and less prepared for each successive year, until the overwhelming feeling completely puts them off of any subject that has prerequisites (like math/science).
I think the more appropriate response is that a finalizer will eventually get called in any ref-counted system (even those that don't properly handle cycles), but the finalizer WANTED to be called at some scope-exit point, but due to the [possibly unforeseen] cycle, must instead wait for some secondary cleanup code which is non-determistically triggered. In a ref-count + mark+sweep hybrid it likely happens when an allocator says memory is too fragmented and thus does a mark+sweep prior to any sbrk calls, in perl it's just before exiting. And more importantly you may have code which relies on a finalizer BUT you can't guarantee that some external code won't INJECT a cycle into your critical region. This is VERY possible in such dynamic languages as perl/python, as your code can easily be mutated on the fly (and thus have undesirable external references to your critical regions).
Thus NO code can have guaranteed deterministic finalizers that have such limitations.
"The reference count lets you discard some of the objects quickly, while the mark and sweep lets you discard the circular references a little more slowly."
'quickly' is debatable if you have a linked list. exiting a ref-count bounded function (or some other scope) could take 60+ seconds if you'd slowly accumulated millions of tree or linked-list nodes (I speak from experience in a perl world). In a copying collector GC, exiting a function is always instantaneous, and in fact, the vacuming of massive transient linked-lists/trees is exactly what copying collectors are good at (as they don't require any work at all). In both cases, allocating new memory might require some jiggering. In arena based ref-counted allocators (used in perl, again not familiar w/ Python's memory internals), if a free arena of a desired size doesn't exist, you search for larger arenas to segment into your desired arena size (thereby fragmenting memory). Over time your arenas get fragmented and thus you have to do some coallesing (either at allocation time or at freeing-time), and depending on tolerances/heuristics (if any) you could trigger wasteful thrashing (lots of memory book-keeping that's continuously never used). You could just use a buddy system allocator, but then you'd have a crap-load of wasted memory (unusable slack-space) in various use cases. Now in GC, you also have a lot of bookkeeping overhead (when doing an eventually necessary mark-and-sweep), but the copying-collector portion is pretty damn fast (especially with allocations, theoretically only requires 2 CPU instructions), and even when you don't have a lot of transient memory. The throughput is certainly better with copying collector + occasional mark+sweep, but your pause times may be unacceptible, and of course, you don't get time-guarantees on finalizers (as a mark+sweep may NEVER happen if you have too much transient memory - ironically the desired case).
Now I'm not sure how python's hybrid works (I know that perl does a full reference traversal at perl-exit time to trigger all finalizers, obviously that's a radically different algorithm), but one thing it MIGHT do is not traverse reference chains on a ref-decriment == 0, and leave the rest up to the GC. That might give the best of both worlds. Large direct-referenced handles are freed immediately (even if dozens of such references exist), but those ref'd 2 or more indirections deep must wait for a mark+sweep.
Wow, I've done a lot of Java development and have never had a need for a finalizer. So while you may have a niche need in your C++/Java work, you certainly don't represent a majority of use-cases, and thus I can disregard your claim of Java's failure. There are many many other programming paradigms for resource cleanups. try-catch-finally (or better yet, pass a runnable to try-catch-finally processor to guarantee consistent resource-management). One particularly elegant form is Thread-Local Transactions (if your use-case can support them). The medium-weight spring-library provides a slew of these resource-safe 'executors', though they're really just simple convenience utilities where you could roll your own. Basically any resource that you want guarantees that you won't accidentally leave open, explicitly register with some framework that at some exit-point, items will be cleaned-up. (In a transaction model, this is the post-end-transaction phase - called after rollback or commit, and whether or not you are exiting with an exception).
" I am so sick of people involving Christianity whenever Scientology comes up" Odd, most atheists I'm aware of are either indifferent or anti-religious. Personally I'm an anti-religion agnostic, but whatever.
To an anti-religious activist - sort of the same type of person as the anti homosexal marriage category, but with a different cause - there are deep parallels to the objectionable practices of Scientology and other self-promoting religions. We view the promotion as promoting a delusion and thus charlatanry. Now as an agnost I'm willing to accept that MOST promoters are true-believers in their cause so I want to grant them the right to at least live their delusion to their dying day - I just want to contain them so their advocacy doesn't ruin other people's lives. But the real stinger are the ring-leaders who so rarely practice what they preach - solid gold bath-tubs paid by the sweat of their empoverished flock. Super-mega-churches, who's true goal is to promote an entertainment and awe-inspiration for the purposes of growing the pyramid scheme.
Pyscho-babble with zero accountability (the New Orleans flood was punishment by God - yeah, all those hard working former slaves that didn't live in the brothel district sure had it in by God).
Revisionist history by the authoritarian religions. Catholic priests use to marry, women had a more promanent role, Jews were the enemy (the cause of our ailments), book-burnings for historic evidence that would contradict the authority, bla bla bla.
Frankly, trying to keep the sci-fi origins and inner doctrine secret through legal faschism is tame in moral comparison. Yeah, the flock are abused, but I argue that most flockians are abused subjects - consider how sadistic the Islamo-Judao-Christian God is presented, and thus how massochistic the devote follower must become. Is it really any different?
To non agnosts/Atheists, move along, nothing to see here..
"Religions differ in the demands they make on parishioners and in the control exerted on them" You mean like asking you to go to war, kill and die over some stupid historic dispute or humanly-interpreted divine-plan? Not that I'd want to choose one, but so far I'm not aware of any acts of violence carried out in the name of Scientology.. Can't say the same about the big-three.
So you've got half the "Christian" religions right there. But honestly, I don't think that's a fair categorization either. Take mormonism.. Horrible theology, but an excellent family culture. As a agnositc, I like to pick and choose the mores of different religions / cultures, because there's almost always something good/wise in each religion.
jQuery solves a totally different problem than prototype.. prototype is a bucket of widgets, whereas jQuery is more like a ruby-extension to javascript. It allows you to program in an expressive meta-language. This happens to make widgets easier to build as well, but the key is your custom API on top of library X,Y,Z can be coded using jQuery. I do this with Yahoo YUI all the time, for example.
Can't speak to mootools. But with a few exceptions, jQuery can work in conjunction with other javascript frameworks (zero namespace collisions at least - unless you want to use jQuery as a global in your library)
I assert that raw javascript + CSS + DOM == PITA. I know that some people disagree, but I think they're massochistic (quirks == spice v.s. quirks == productivity-obstacle).
And you point out an important point. Pair-programming doesn't work with vi* as a good vi* person will fully leverage the hundreds of accelerators which provide no visual feedback (which is awesome for editing over slow network connections).
And you wonder why the newbies stand there in depressed frustration..
Pair-programming (including training) requires lots of contextual information. Even a good person is pressed to their limits in being able to remember the path that got them to a point of code, much less understand the purpose/impact of that code-file. What does it do (the name of the file might have helped - is that displayed anywhere?), what files does it use? (Are there any graphical linkages to descriptions of module-names?) Who uses the code? (any ability to search the code for invocation points, or better yet 'list' invocation points).
I find that when I encounter a new piece of code, I need to traverse it linearly to follow a use-case. When an external reference is made, sometimes the name of that reference is sufficient, but often times, I don't trust that the code is immutable, so I need to traverse it to see if bad-coding mutated the state beyond expectation. If you're the passenger, you can't easily follow these trains of thought. And it becomes slightly irritating to constantly ask to inspect the contextually referenced code.
The best thing to do is have the trainee 'drive' and have the experienced one navigate. This keeps the trainee from getting lost/frustrated - quick verbal descriptions will be easier/more-accurate than documentation.
Note these have little to do with the editor. BUT, an editor can GREATLY enhance a trainee's ability to digest new code. See my other post in this thread for a listing of powerful inspection capabilities that are nearly impossible in most editors except theoretically emacs.
Forget 10k lines, that's a 'small project'. Try 100k lines. To the IDE, the only difference is how much memory you need to have installed (for those that cache all symbol names in mem). I currently need about 3 to 4 gig of RAM (the last half gig is for non-editor stuff:)
Variable-completion was done by emacs 20 years ago. That's trivial. Try these features (which I use daily):
* preview-javadoc, preview-function[method] parameter signature/overloaded signatures, preview-jump-to-source, jump-to-source - no mouse needed - I NEVER need API docs, because signatures and view-source is 100% accurate, while [java]docs tend to be stale, but they're still useful to get intended use-patterns. But the time-saving of not going to a web-browser to search for documentation pays for itself (even the premium editors). * version-control visual-diff history overlays on a per-line basis (both annotation graphics and popups) * real-time compiled syntax and LOGIC checking (i.e. 'you're doing something stupid here', annotations) * function/method/field/variable not-used highlights, field assigned-but-not-used (also variable used before assigned, but in java at least that's an error condition) * sub-class, super-class method visual markers * test-code-coverage line-highlights * create-unit-test from method icons. (which go away as you create them) * jump-to-next/prev method (though I sorely miss the vi jump to matching paren, editors that optionally support vi accelerators tend to lose most of the IDE's niceness in that mode WHATS WRONG WITH YOU PEOPLE??) * Quick at-a-glance file-has-errors, file-tree-path-has-errors * Quick at-a-glance file/path has changed since last VCS checkin * Rename variable (invasive contextual search, even into HTML files that would use template attributes), Rename method, Rename class, extract interface from class (renaming all references to former class to use the new interface where possible) * Safe-delete (check to see if anything is meaningfully using this symbol - meaningful may optionally include references in comments and or templated code such as used in HTML) * Delegate structure/object (use pass-through getters/setters, so you can 'proxy' the structure/object) * real-time editing of actively debugged code!!!! Meaning if while stepping through the debugger I see a bug, I can make a change, and the next time through the loop, the new code is applied. (don't know if it works in C, but definitely interpreted languages - java has some limitations - can't change signatures only method-bodies) * Can step through HTML as it's rendered on the back-end, some support for debugging the javascript that's dynamically generated (I haven't used this part, and firefox's firebug is often more than sufficient) * At a click auto-decompile 3'rd party source-less code. (assuming it hasn't been obfuscated - though even then, the logic can be reverse-engineered). And by at-a-click, I mean, I'm looking at my code, I see a method call to a 3'rd party library, I move my cursor to it and hit Control-G, and boom - decompiled as if it were my own code, sitting in a temp path which can be included in my workspace. I can then actually edit this code and ship it with my code. Fixing 3'rd party bugs in SECONDS. Try doing that with emacs, much less vim. Of course you have to be conscious of licensing issues, but what else gives you this much power in off-the-cuff open-source contributions??? As a result, my overworked schedule has allowed me to submit patches to open-source projects with no more than half an hour of total distraction time (on the company dime). * If 3'rd party source-code is available (and auto-linked via something like maven), then you're even better able to understand their code, because white-space is often a subtle form of documentation (these 5 lines are related, then there's a double-space then new code). I often find that MUCH more descriptive than a "//". Also, you're patches are easier to create because you have actual line-
Slashdot Mirror
This is categorized under explicit backup strategies, whereby most people don't have one or wouldn't know how to go about doing it.
Well, the UI is the most resource intensive aspect Linux from my perspective. Conversely, the java VMs on android are probably it's greatest resource hog. Windows and MAC have more "optimized" UIs, whereas most things on Linux UI are X-based which means most communication is serialized through a single socket and much information is stored redundantly in the app and the X-server. Hell, in recent versions of Fedora I have a problem where my X-server grows to over a gig of RAM even when all windows have been closed. I hate the fact that I have to log-out/in-again because of mem-leaks in either X or gnome (can't determine which). Ironically, I still prefer gnome over Mac/Windows UIs in terms of it's expressiveness / adaptability to my needs.
So it makes sense to provide OS hooks for an alternate UI mode.. Hell there's dedicated VGA mode for games in existing Linux. Gnome/KDE are not light-weight (though X can be), and I can't imagine how you could retool them to be. Much less how you could to this in a way that supports existing KDE/Gnome/X apps.
Remember, we're talking the slowest possible hardware above cell-phone-grade that we're talking about here. Big screen and keyboard, but essentially a cell-phone/PDA on the backend. I wouldn't be surprised if the browser is required to be full screen like on a cell.
Further, there is a serious argument to be made about low-performance devices and the lack of desire to store sensitive / loosable information on them. Viruses + hardware failure + hardware upgrade means losing your data. While some people avidly setup backup strategies, it's applied with lesser diligence to lower-end devices. And if you're buying on the cheap, than backup solutions cost extra thereby defeating the point. Why buy a $100 netbook then have to buy a $90 external backup hard drive?
I'm not saying this isn't valid, I'm saying that there are massive groups of people that are affected by quality-control issues and migration strategies of software vendors including MS, and google is allegedly attempting to obviate that aspect entirely by making low-cost devices 100% online.
I do see a valid use-case.. 3'rd world, poor US citizens, virtually every high school/elementary school.
Of course google is merely trying to promote it's online dominance and we should take pause. But other than the OS, I'm not sure that this ties your experience to google (though maybe their search engine/user-profile - but anti-trust will eventually kick in).
Who said backup? People see what they want to see.
BackupPC server: Linux SW RAID-1 (3 way, leaving a DVD slot) mitigates bad-blocks.. On first smart error, throw the $30 disk out and plop in a new one.
Desktop: Linux SW RAID-1 (2-way).
External USB/NAS for the BackupPC server.
Judicious manual use of subversion for local configuration files in read-only checkpoint mode (so history never changes and thus is safe/efficient to backup). This is slightly redundant with BackupPC's version-checkpoints, but allows a compact infinite history, and visual deltas.
Occasional off-site rotation. (possibly using Amazon storage).
For servers, at my work, we do almost the same thing, but use hot-swappable hardware raid controllers with RAID-01, and we use LVS snapshotting for consistency (every try to rsync actively changing data?) and for apps that support it, explicit dump operations (like mysqldump) to produce wholly consistent point-in-time backups. For our light-but-real-time servers, we ALSO use drbd (block-level network replication) along with heart-beat.
Frankly, I'm rather surprised by the backlash against RAID here.
"If the application was purely CPU bound, and Y wasn't giving me 35% more than X, I'd complain."
Huh? Why should a specific APP be expected to achieve that max theoretical performance increase that a contrived benchmark (specInt, etc) rates? While this class of bench marks is based on 'real world apps', nobody uses those apps anymore.
You can write two 'CPU bound' apps that have completely different branch-patterns and memory-patterns. One with great instruction-sequentially and mem-locality (and thus deep-pipeline utilization and highly cacheable even though it exceeds the cache size) and one which makes effectively random walks through memory with contingent random code-jumps (such that DRAM banks are constantly powered up and down). You'll totally trash the memory performance and thus your memory bus bandwidth is bumpkiss.
So if you are currently achieving say 60% max-theoretical throughput on CPU-1, then what the author is suggesting is that CPU-2 should achieve 135% * (60% * CPU-1). But the design decisions of the new CPU might be such that the particular code-flow of the target app are actually WORSE (i.e. a longer pipeline visa v. the Pentium 4). The issue might be more subtle, such as fooling the branch-predictor logic (which is complex). Or it could be that the data-dependent random memory walks are such that the parallel memory channels CAN'T be utilized effectively. So BW and parallel chips don't make up for fundamentally rate-limited random-access latency.
The point is, ALWAYS sample the new hardware and make mass purchasing choices based on your personal cost-benefit analysis.. Bitching to the vendor is unfruitful - choose alternate purchasing strategies.
"with two different genes in the same place, the non-broken one can make up for the mutated one, but with inbreeding there's no redundancy."
Speaking from from high-school biology decades ago.. There were dominant and recessive genes (I'll call D and R) - neither necessarily broken. DD, DR, RD utilize the D gene and only RR activates the recessive. Natural selection is supposedly such that if gene-R would not be able to survive in a given environment, RR's would die out, BUT they'd still be passed in the gene pool such that it's possible that an RR will occur on occasion.. These should be still-births or otherwise die out before reproducing. From a survival perspective, this allows R to not become extinct and thus if R ever did become necessary, some fraction of the population (that hadn't died of RR yet) would now BECOME the dominant genetic code.
In this environment reversal, I didn't understand whether R could become dominant or whether D would necessarily have to become extinct in the population (which would seem to defeat the point).
But in terms of in-breeding, you have a much higher probability of getting a greater number of RR combinations for a given person (of your 25k some odd genes), since you have far less variation.
But here's what always struck me, and I never fully got this impression from the scientific community.. Lets say all the above are true. Then a small community becomes isolated, such that it's forced, ultimately to inbreed (there have been many great-dyings in mans history, to say nothing of earth's history). Your first generation will have a LOT of RR's, and they'll die out... BUT if you have a sufficient number of DD's, then you'll actually produce super-healthy children. Presumably the entire community have a better part of the complete suite of valid D's, just mixed in with the occasional R.. This massive in-bread children-making process is going to have a lot of death, but in the end, a cleansed population.
Since high school, I've been led to believe this is a dramatic over-simplification of genes. So the model probably breaks down, except to say that statistically, in-breads have greater ratios of down-syndrome and that man has survived mass population decreases.
Well, as best I can understand it (listening to a lot of talk-radio - so don't have hard references, sorry). The old testament had dozens prophecies. One of which mentioned a young-woman giving birth to a bla bla in Hebrew. The translation CAN be interpreted as a virgin birth (as the wording is sufficiently vague). So when people tried to retroactively apply all the prophecies to Jesus (ultimately recorded in Greek), they flat out labeled the Mary birth as virginous. So it's harder to claim the Greek is mistranslated, BUT, it's part of a larger argument that little if any prophesy was actually fulfilled (Jews weren't freed, etc), and are thus ultimately questionable embellishments that the Nicea council chose to go with some - 300 years after the events in question - based on recordings some 60 to 110 years post-facto.
This, of course, begs the issue of whether prophesies are relevant to begin with (since much of the Nicea justification was the fulfillment of Prophecy - that's what's echoed in Catholic church).. Consider our modern obsession with Nostradamus every season (or even Deja-Vu). The argument I would make is that either prophesies don't exist - they are man's struggle with statistical behavior. Or they DO exist but in divinely fucked-up ways. Such that an Edgar Casey / Nostradamus are non-religiously-important, yet Mohammud/old-testiment (and loosely speaking Jesus) IS. Islam of course conveniently says Mohammud was the last one.
To me, accepting prophesy opens a can of worms such that the world makes tremendously less sense and is more scarry than rejecting it. You've got Angry daemons who lie to you through dreams competing with benevolent Angles whispering secrets - you've got Christian prophesies that there will be great deceivers, you've got all Christian/Islamic morality tangled with power-hungry figure-heads that history proves time and again were ultimately immoral. So it's impossible to be religious and a believer and have any assurance that you're acting morally (outside of the incredibly obvious moree' of don't fuck with people). The simple recognition that alpha-males naturally will deceive as necessary to achieve power, and that people are susceptible to superstition is a much simpler explanation of history.
Now now.. Religion is incredibly important. It's just an anachronism these days that people are unwilling to accept. Just like the horse and buggy was critically useful at one point in time.
:/
Consider that you live along the Nile and you have to maintain a peaceful order of how people utilize this scarce but incredibly life-given resource. You could just kill people that didn't do what you said, but eventually people would find ways of sneaking around the law.. So you invent a Santa-Clause - someone that knows when you've been naughty. Even if it doesn't spook you, it might spook the police-officer who's in charge of watching out for the scarce resource. Spook him enough that he can't be bought off. Sure some fraction of police can still be bought off, but the Santa-Clause thing is sure to give you a greater fraction of adherents.
It's wasn't even entirely artificial.. The world of course had it's mystical properties to the simpler man - superstition was already there.. religion was just the socialization of these mystical properties.
I have friends/family in atheistic countries, and the thing that struck me most about them is how superstitious they are (given their high degree of education). Borderline voodoo rituals go on there. I don't know how much of that relates to the Zoroastrian regional influence or how much the human need to personify statistically rare occurrences are. Growing up in a Catholic religion, we of course laughed at all things superstitious (ignoring the irony of our own culture), and so my switch away from Catholicism was more-or-less clean. But if you didn't have the transition from unquestioned-faith to faithless, I suspect you might be susceptible to random unsubstantiated explanations.
Oh well, I'll find out when my kids grow up.
It was common practice to free people from the cross while still alive. So given the deceitful nature of other portions of the bible, I'd say there's a greater likelihood that either the Jesus character was more a legend-status after his big public speeches (and all subsequently 'documented' events are suspect, albeit 60 to 110 years later), or that he indeed was partially alive after being pulled down.
Both explanations are far more plausible than the poorly described and seemingly nonsequiter resurrection. Nonsequiter because it makes no sense for him to 'die for our sins' when death was merely symbolic because he had the 'magic' ability to retake human form again. Where's the sacrifice? Remember, the story isn't that God forgave both Man and Jesus then gave Jesus his body back (which at least would make sense from a story perspective).. It was JESUS who ressurected his own damn self because he WAS GOD. Even when I was a devout catholic this part made no sense. That's up there with God inventing the prism effect out of the blue one day to prove to Noah that he wouldn't toast the earth again. THINK FOR YOURSELF PEOPLE.
Silly discussion.. Lazarus and Jesus didn't die. Simulated 'rebirth' was a symbolic pagan ritual popular in the day. This was known even before the recent discovery of 'lost' testaments - which more-or-less proved the mis-historical-representation when Jesus had a conversation with Lazarus before 'resurrecting' him.
"It just consumes way too much memory, and starts damn slow."
Sigh. I've said this 100 times.. server apps (as relevant to this COBOL discussion) don't have startup time. They are up for months at at time (years even). Please distinguish between client-side apps and server-side apps.. As java-programming only exists in client-side-apps these days as server-interfaces (for fast-to-build, yet bug-free coding of mission-critical-apps) and cell-phone-apps (for hardware-portability). For this class of client-side apps, yes you can bitch about memory usage and startup time. Though hopefully memory usage shouldn't exceed 150Meg (a typical firefox executable). Server-apps, on the other hand have completely different requirements.
A 'server' that runs java costs between $900 to $10,000. What is the cost of 2Gig of memory? $100? $200? Give me a break. Further, I usually recommend only using the 32bit JVM and thus <= 2Gig of JVM memory (typically caping out at 1Gig). Thus the worst stop-the-world GC-collection time is on the order of 1 second. This pause sacrifice gives you better overall throughput. There are server-app types that require 16, 32, 64 or 128Gig of RAM however, and thus you need the 64bit JVM (64bit pointers increase mem-overhead and cache-coherence) and can't risk the nearly-a-minute pause-times, so you need incremental collectors (with an additional 15% performance loss). But for this, I usually say that such large memory foot-prints are best handled by consolidated network-APIs. This allows you to cluster the apps on smaller, cheaper hardware, and then have a pair of larger-memory hardware on the back-end. But at this point, is the back-end really any different than a traditional large-mem database (such as mysql-INNODB or mysql-cluster/NDB or memcached)?
And as for:
"here's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good..."
If you're writing server-code (for targeted $10k hardware clusters), I should hope you're not paying somebody straight out of high-school. Or at least have coding-standard and code-reviews with senior staff.
Otherwise, code to google-apps and run a castraded java-api that doesn't really let you waste resources and doesn't have startup-time issues. Actually, it's a pretty good segway for server-freshmen.
JIT code is slow? Or JITing the code is slow? When I run bench-marks, the average-benchark speed continually gets faster and faster as I increase the number of iterations. This is because the JIT continuously re-assesses basic-blocks to determine if coallesing is worth the expense. This means:
A) code is NOT JIT'd at first, even with -server.. ONLY after a min-number of passes (why JIT initializtion code that'll never run a second time?)
B) book-keeping to determine what to JIT and what not to JIT adds extra overhead for rarely used code
C) Even JIT'd code is continuously evaluated to determine if larger execution-flow-patterns are possible.. So the same code might be JIT'd 50 times, each time being aggregated into larger bundles of contiguous raw assembly
Thus, for short-lived applications, the JIT only provides marginal benefit if not a detriment (which is why the google android's JVM does ZERO JIT, and instead uses an alternate byte-code which is more efficient to cold-start).
But, for servers (web-servers and mainframe code which will batch process all night long), you're talking about relatively small chunks of code (out of the overall loaded library) that are highly reused. It's entirely possible that an entire web-page can be inlined into a single chunk of assembly (though it's a stretch). Not even PHP can do this (at present).
Basically typical code is complex because of optional flow-paths (if-statements, etc).. But in highly repetitive batch/server processing, there are a handful of paths which make up maybe 99% of execution, and thus can be rewritten in a way that in C would be horrendous (though certainly possible).
Doing code-analysis to prove that an array index will never be out of bounds is expensive.. But once done, you can remove a lot implicit assembly-code. So general-purpose 3'rd party code can be almost fully optimized away. You get the best of both worlds.. High-degree of defensive coding + optimized execution. The cost is the ramp-up-time (and an immodest but reasonable memory foot-print).
For single-app-servers, throwing 2 gig of RAM is NOTHING ($100 v.s. $5,000 ???), so I'm frustrated when I hear people bitch about memory consumption.. Memory use is bounded, if not, then you have a coded memory-leak and that's not the JVM's fault (usually due to misconfigured-as-unlimited in-mem caching - usually a disk-spill-over-caches that unknowingly (to the coder) retains headers in-mem).
C# might be better than java, but Java is an order of magnitude better than Cobol. And they weren't building an 'open-source' MS + C# stack. And Linux + mono stack is no where near the performance capability of MS C# or SUN/IBM Java. Consider that 90% of the java-byte-code is rewritten as highly optimized assembly in a server environment (often better than hand tuned C/C++). You're assessment of java is clearly wrong.
And as to the basic premise of this thread that java is a lesser programming environment - speaking from someone that favored C over C++ for 10 years, I loath going back to open-source C projects v.s. Java projects. A good editor makes reverse engineering Java-code take minutes instead of hours for C. The static-typing nature of a Java development environment means nearly 90% guarantees that code does what code means.. no side-effects, no package/name-space trickery. An editor can be nearly 90% correct in saying "here are all the code points that utilize this class/method/field". So I can reverse engineer how the code is used. I can walk through code, not worrying WHICH of 50 #ifdef's/alternate-.o files the compiled code is going to actually need - so 'drill-down-to-method' is concise. The remaining 10% is due to reflective/aspect-oriented code (sadly now taking over in the Java space). Thankfully much of the AOP is compartmentalized such that editors have a very good idea of where the use-points and jump-points should be.
If you don't believe me, TRY and read through all the lines of apache or mysql-INNODB, and compare that to running through the lines of java-tomcat or java-hsqldb. And tomcat is FASTER than core apache for static files (though of course there are plugins that do various things in a specialized way faster).
Reading code is VERY much a function of seeing both the bigger picture and the details from the same vantage point. The greater a developers perspective into code, the greater his ability to assess the correctness and more importantly the extensibility of code.
C-code, in general is not extensible. It's tool-box based. C++ is better, but most methods are not declared virtual, so they're essentially static c-functions for the purposes of a 3'rd party. Even only decent java code is fully extensible - especially when written with interfaces + injection-oriented design (the latter only being a recent trend). Thus even your toolboxes can be used in ways the originators never imagined possible. The reason one might not declare methods as virtual in C++ are performance, but thanks to Java JIT, all functions are treated as 'final' in the end product - all virtual methods are effectively inlined where practical. Thus there' no reason to artificially castrate your java code for the performance Gods.
And don't forget, nobody runs COBOL in as a web-plugin.
The failure of American pupils is probably not due to the way the subject is taught, but rather because they don't feel the pressure to excel like students in other cultures.
Huh? Getting into college isn't an extremely pressing/taxing/competitive ordeal?
I'll tell you why US students are degrading in test-worthy performance: Grade-inflation forced down the throats of schools by bitchy parents who can't believe their kid got a C when in prior years they'd gotten an A (most likely due to grade-inflation having to slowly work it's way up and through college). This does a tremendous disservice to the children, as they are less and less prepared for each successive year, until the overwhelming feeling completely puts them off of any subject that has prerequisites (like math/science).
I think the more appropriate response is that a finalizer will eventually get called in any ref-counted system (even those that don't properly handle cycles), but the finalizer WANTED to be called at some scope-exit point, but due to the [possibly unforeseen] cycle, must instead wait for some secondary cleanup code which is non-determistically triggered. In a ref-count + mark+sweep hybrid it likely happens when an allocator says memory is too fragmented and thus does a mark+sweep prior to any sbrk calls, in perl it's just before exiting. And more importantly you may have code which relies on a finalizer BUT you can't guarantee that some external code won't INJECT a cycle into your critical region. This is VERY possible in such dynamic languages as perl/python, as your code can easily be mutated on the fly (and thus have undesirable external references to your critical regions).
Thus NO code can have guaranteed deterministic finalizers that have such limitations.
"The reference count lets you discard some of the objects quickly, while the mark and sweep lets you discard the circular references a little more slowly."
'quickly' is debatable if you have a linked list. exiting a ref-count bounded function (or some other scope) could take 60+ seconds if you'd slowly accumulated millions of tree or linked-list nodes (I speak from experience in a perl world). In a copying collector GC, exiting a function is always instantaneous, and in fact, the vacuming of massive transient linked-lists/trees is exactly what copying collectors are good at (as they don't require any work at all). In both cases, allocating new memory might require some jiggering. In arena based ref-counted allocators (used in perl, again not familiar w/ Python's memory internals), if a free arena of a desired size doesn't exist, you search for larger arenas to segment into your desired arena size (thereby fragmenting memory). Over time your arenas get fragmented and thus you have to do some coallesing (either at allocation time or at freeing-time), and depending on tolerances/heuristics (if any) you could trigger wasteful thrashing (lots of memory book-keeping that's continuously never used). You could just use a buddy system allocator, but then you'd have a crap-load of wasted memory (unusable slack-space) in various use cases. Now in GC, you also have a lot of bookkeeping overhead (when doing an eventually necessary mark-and-sweep), but the copying-collector portion is pretty damn fast (especially with allocations, theoretically only requires 2 CPU instructions), and even when you don't have a lot of transient memory. The throughput is certainly better with copying collector + occasional mark+sweep, but your pause times may be unacceptible, and of course, you don't get time-guarantees on finalizers (as a mark+sweep may NEVER happen if you have too much transient memory - ironically the desired case).
Now I'm not sure how python's hybrid works (I know that perl does a full reference traversal at perl-exit time to trigger all finalizers, obviously that's a radically different algorithm), but one thing it MIGHT do is not traverse reference chains on a ref-decriment == 0, and leave the rest up to the GC. That might give the best of both worlds. Large direct-referenced handles are freed immediately (even if dozens of such references exist), but those ref'd 2 or more indirections deep must wait for a mark+sweep.
Wow, I've done a lot of Java development and have never had a need for a finalizer. So while you may have a niche need in your C++/Java work, you certainly don't represent a majority of use-cases, and thus I can disregard your claim of Java's failure. There are many many other programming paradigms for resource cleanups. try-catch-finally (or better yet, pass a runnable to try-catch-finally processor to guarantee consistent resource-management). One particularly elegant form is Thread-Local Transactions (if your use-case can support them). The medium-weight spring-library provides a slew of these resource-safe 'executors', though they're really just simple convenience utilities where you could roll your own. Basically any resource that you want guarantees that you won't accidentally leave open, explicitly register with some framework that at some exit-point, items will be cleaned-up. (In a transaction model, this is the post-end-transaction phase - called after rollback or commit, and whether or not you are exiting with an exception).
So we almost had a cult president. AWESOME!
" I am so sick of people involving Christianity whenever Scientology comes up"
Odd, most atheists I'm aware of are either indifferent or anti-religious. Personally I'm an anti-religion agnostic, but whatever.
To an anti-religious activist - sort of the same type of person as the anti homosexal marriage category, but with a different cause - there are deep parallels to the objectionable practices of Scientology and other self-promoting religions. We view the promotion as promoting a delusion and thus charlatanry. Now as an agnost I'm willing to accept that MOST promoters are true-believers in their cause so I want to grant them the right to at least live their delusion to their dying day - I just want to contain them so their advocacy doesn't ruin other people's lives. But the real stinger are the ring-leaders who so rarely practice what they preach - solid gold bath-tubs paid by the sweat of their empoverished flock. Super-mega-churches, who's true goal is to promote an entertainment and awe-inspiration for the purposes of growing the pyramid scheme.
Pyscho-babble with zero accountability (the New Orleans flood was punishment by God - yeah, all those hard working former slaves that didn't live in the brothel district sure had it in by God).
Revisionist history by the authoritarian religions. Catholic priests use to marry, women had a more promanent role, Jews were the enemy (the cause of our ailments), book-burnings for historic evidence that would contradict the authority, bla bla bla.
Frankly, trying to keep the sci-fi origins and inner doctrine secret through legal faschism is tame in moral comparison. Yeah, the flock are abused, but I argue that most flockians are abused subjects - consider how sadistic the Islamo-Judao-Christian God is presented, and thus how massochistic the devote follower must become. Is it really any different?
To non agnosts/Atheists, move along, nothing to see here..
'modern religions'?? So mormons and Jehova's witnesses (who do advocate segregation of life from non-believers) aren't modern?
"Religions differ in the demands they make on parishioners and in the control exerted on them"
You mean like asking you to go to war, kill and die over some stupid historic dispute or humanly-interpreted divine-plan? Not that I'd want to choose one, but so far I'm not aware of any acts of violence carried out in the name of Scientology.. Can't say the same about the big-three.
So you've got half the "Christian" religions right there. But honestly, I don't think that's a fair categorization either. Take mormonism.. Horrible theology, but an excellent family culture. As a agnositc, I like to pick and choose the mores of different religions / cultures, because there's almost always something good/wise in each religion.
jQuery solves a totally different problem than prototype.. prototype is a bucket of widgets, whereas jQuery is more like a ruby-extension to javascript. It allows you to program in an expressive meta-language. This happens to make widgets easier to build as well, but the key is your custom API on top of library X,Y,Z can be coded using jQuery. I do this with Yahoo YUI all the time, for example.
Can't speak to mootools. But with a few exceptions, jQuery can work in conjunction with other javascript frameworks (zero namespace collisions at least - unless you want to use jQuery as a global in your library)
I assert that raw javascript + CSS + DOM == PITA. I know that some people disagree, but I think they're massochistic (quirks == spice v.s. quirks == productivity-obstacle).
Just enable jQuery.noConflict() then use jQuery.foo() like I do.
And you point out an important point. Pair-programming doesn't work with vi* as a good vi* person will fully leverage the hundreds of accelerators which provide no visual feedback (which is awesome for editing over slow network connections).
And you wonder why the newbies stand there in depressed frustration..
Pair-programming (including training) requires lots of contextual information. Even a good person is pressed to their limits in being able to remember the path that got them to a point of code, much less understand the purpose/impact of that code-file. What does it do (the name of the file might have helped - is that displayed anywhere?), what files does it use? (Are there any graphical linkages to descriptions of module-names?) Who uses the code? (any ability to search the code for invocation points, or better yet 'list' invocation points).
I find that when I encounter a new piece of code, I need to traverse it linearly to follow a use-case. When an external reference is made, sometimes the name of that reference is sufficient, but often times, I don't trust that the code is immutable, so I need to traverse it to see if bad-coding mutated the state beyond expectation. If you're the passenger, you can't easily follow these trains of thought. And it becomes slightly irritating to constantly ask to inspect the contextually referenced code.
The best thing to do is have the trainee 'drive' and have the experienced one navigate. This keeps the trainee from getting lost/frustrated - quick verbal descriptions will be easier/more-accurate than documentation.
Note these have little to do with the editor. BUT, an editor can GREATLY enhance a trainee's ability to digest new code. See my other post in this thread for a listing of powerful inspection capabilities that are nearly impossible in most editors except theoretically emacs.
Forget 10k lines, that's a 'small project'. Try 100k lines. To the IDE, the only difference is how much memory you need to have installed (for those that cache all symbol names in mem). I currently need about 3 to 4 gig of RAM (the last half gig is for non-editor stuff :)
Variable-completion was done by emacs 20 years ago. That's trivial. Try these features (which I use daily):
* preview-javadoc, preview-function[method] parameter signature/overloaded signatures, preview-jump-to-source, jump-to-source - no mouse needed - I NEVER need API docs, because signatures and view-source is 100% accurate, while [java]docs tend to be stale, but they're still useful to get intended use-patterns. But the time-saving of not going to a web-browser to search for documentation pays for itself (even the premium editors).
* version-control visual-diff history overlays on a per-line basis (both annotation graphics and popups)
* real-time compiled syntax and LOGIC checking (i.e. 'you're doing something stupid here', annotations)
* function/method/field/variable not-used highlights, field assigned-but-not-used (also variable used before assigned, but in java at least that's an error condition)
* sub-class, super-class method visual markers
* test-code-coverage line-highlights
* create-unit-test from method icons. (which go away as you create them)
* jump-to-next/prev method (though I sorely miss the vi jump to matching paren, editors that optionally support vi accelerators tend to lose most of the IDE's niceness in that mode WHATS WRONG WITH YOU PEOPLE??)
* Quick at-a-glance file-has-errors, file-tree-path-has-errors
* Quick at-a-glance file/path has changed since last VCS checkin
* Rename variable (invasive contextual search, even into HTML files that would use template attributes), Rename method, Rename class, extract interface from class (renaming all references to former class to use the new interface where possible)
* Safe-delete (check to see if anything is meaningfully using this symbol - meaningful may optionally include references in comments and or templated code such as used in HTML)
* Delegate structure/object (use pass-through getters/setters, so you can 'proxy' the structure/object)
* real-time editing of actively debugged code!!!! Meaning if while stepping through the debugger I see a bug, I can make a change, and the next time through the loop, the new code is applied. (don't know if it works in C, but definitely interpreted languages - java has some limitations - can't change signatures only method-bodies)
* Can step through HTML as it's rendered on the back-end, some support for debugging the javascript that's dynamically generated (I haven't used this part, and firefox's firebug is often more than sufficient)
* At a click auto-decompile 3'rd party source-less code. (assuming it hasn't been obfuscated - though even then, the logic can be reverse-engineered). And by at-a-click, I mean, I'm looking at my code, I see a method call to a 3'rd party library, I move my cursor to it and hit Control-G, and boom - decompiled as if it were my own code, sitting in a temp path which can be included in my workspace. I can then actually edit this code and ship it with my code. Fixing 3'rd party bugs in SECONDS. Try doing that with emacs, much less vim. Of course you have to be conscious of licensing issues, but what else gives you this much power in off-the-cuff open-source contributions??? As a result, my overworked schedule has allowed me to submit patches to open-source projects with no more than half an hour of total distraction time (on the company dime).
* If 3'rd party source-code is available (and auto-linked via something like maven), then you're even better able to understand their code, because white-space is often a subtle form of documentation (these 5 lines are related, then there's a double-space then new code). I often find that MUCH more descriptive than a "//". Also, you're patches are easier to create because you have actual line-