How do you speculate that greenification reduces needed energy? Consider that as man gets wealthier he wants: A) Air conditioning B) Lighting C) transportation D) electrical appliances.
We'll simply state that we're producing a generation (myself included) that's addicted to air-conditioning compared to even a preceding generation.
On the transportation front - we're talking about plugin hybrids as being the most practical 'green car'. In my opinion, that's a good thing, but it INCREASES energy demands, not decreases them.
Technically OIL is a geo-thermal byproduct, so it's as natural as steam-veins in iceland. So the question becomes whether non-coal/oil fired transportation is more efficient on the aggregate. I'll even assume, for sake of argument, the eventual treaties and technologies which support mobile CO2 sequestration.
In other words, in an apples to apples comparison, is wind (rare-earth allocations) + power-lines + metro battery storage + AC/DC conversion + LiIon storage (more rare-earth allocations) more efficient than local-motor oil burning?
I'm talking about efficiency based on Joules of energy; not dollars - which are affected by other factors.
There's a simple economic solution.. But first, the heart of the problem.
Nobody is allowed to know the exact reserves of Saudi-Arabia, though we have a decent idea about the rest of the world (at least in terms of active oil wells). So we're acting on a sort of desperate optimism. 'Of course they're plenty to be had'.. So speculation and hoarding isn't going on as it SHOULD.
If, on the other hand, we were able to release the information of current reserve readiness to the general public, then a count-down clock would effectively have started, and hoarding would go rampant.
This of course jacks the price of oil, and consequently hurts the world economy. But also massively increases spending in alternative energies.
You somewhat get the best of both worlds.. High oil prices with plenty of reserves.
Eventually alternatives succeed and oil futures decrease in value.. The fore-knowledge of this brings about the perfectly competitive market - such that efficient levels of R&D v.s. reward can find their way through.
Ahmadinejad is a liar, but in his religion, it is acceptable to lie to infidels.
However, I think you misrepresent/over-simplify his stated views on Israel. I listened painfully, to his interviews on his recent visit to the US/UN. (Sorry too lazy to look up quotes.)
But what he says is that: If Nazi Germany committed a genocide, then why not graft land from Germany and give it to the Jews instead of taking land from the middle east? Also, why weren't the Gypsies given their own land? They were equally persecuted.
Essentially, he reasons that the holocaust is not an excuse for the current situation.
Now his going-forward recommendations were to grant voting power to the residents (namely the Palistinians) and he presents the non-improbable outcome that they'd evict the Israeli's. So obviously this isn't going to happen, so he's not a pragmatist.
But the blanket assertion that he's crazy isn't the case, in my opinion.. He's carefully crafting diplomatic words that maximizes his position.
At the end of the day, we don't care about the history - in fact, the history of modern Israel is a lot more complex, and I don't even fully understand it - sufficient to say, the holocaust was not the most deciding factor. What we care about is that it's in our interests to have strong allies in the region. Look at teetering Christians African nations if you don't believe me.
How is only FF 3.5 supporting trim useful to designing a web page? You still have to wrap it in a function to support other browsers don't you?
Your turbo C analogy doesn't work because that is compile once deploy everywhere with no consequence.
The best you can say is that trim will be more efficient in FF 3.5 via the library. But with JIT becoming more common, you'd get that anyway in newer browsers.
== this while reading the documentation on which object is passed as the this in various contexts may sound easy - What happens when you have 3 or 4 layers of abstraction that may or may not effectively swap out the this object such that a given function can not guarantee what fields/methods exist on the this object.
Maybe I'm just use to methods being tied to their associated class - being an old foggie. But Ive had a lot of bugs in jQuery callbacks because the this variable was of an unexpected source.
I understand your point about prototype vs deep C++ inheritance though. But neither C++, Java, Perl nor JS feel right to me wrt OOP. They all have serious code-clarity problems when you fully leverage their capabilities as anything more than glorified hash-maps / c-structs.
feels to me like bad design. What is the usefulness of all these possible combinations of truthiness? Perl had similar degrees of type cooersion to easily compare unrelated datatypes, but they at least all seemed obvious to me - the principle of least surprise / similar things look similar, different things look different. But JS type-coersion/truthiness doesn't minimize surprise to me. Here replacing undefined with an exists operator would do the trick. You dramatically reduce the number of combinations of truthiness at the expense of some code verbosity.
Granted there is one known edge case in perl that can prevent proper type cooersion for string concatenation, and there isn't an equivalent Number(), String() type-cast. But I'd only ever encountered it twice in my whole life.
No cache coherence so dont get your hopes up for general computing. though its probably not as bad as the PS3 chip with no virtual memory in the multi-core processing part.(forget the name.. aaaaarg)
Im not sure "separate computer" is accurate. you get copy on write performance benefits. So fork based processes would work like gang busters. Multi threading COULD work if they never modified common data pages. I'll just assume they have some kind of support for high performance mutexes.
What is worse is that theyve done away with cache coherence. So I dont think you can take a 48 thread mysql / java process and just scale it. You COULD use forked processes that don't share much. (ie postgres/apache/php).
"few people notice because all but the most recent implementations are resource hogs, and the most used API (the DOM) is hideous and causes aneurisms for multiplatform deployment"
Not quite sure where you're seeing people complaining about resources. Flash / java-applets still takes the cake there.
DOM isn't that bad. It's never been a problem for me. Though I prefer to concatenate an HTML string and set the innerHTML - but that's just me.
The offing of "aneurisms on multiplatform deployment", however is where I really take difference. How can the platform be legitimate if it doesn't work on anything but one version of one browser??? Thus you have to have if-statements for each browser (either explicitly or hidden via a library)??
Maybe you're use to being anally raped by "cross platform C/C++". But I've been spoiled over the past 20 years with standards at the language level and compensator's at the compiler level. (That or just using C for one targeted platform - which I know, makes me less of a Man; but the right-tool-for-the-job I always say)
For more, see my post above: http://slashdot.org/comments.pl?sid=1462628&cid=30296518
Why does everybody keep mentioning DOM? wtf does that have to do with with any of the complaints I listed? In fact, I think the DOM implementation of most browsers is sufficient. Just don't muck with table DOM elements and you're fine. DOM is just one of several libraries javascript + browser provides.
My complaint is stupid things like:
myinput = myinput.trim();
can work on some browsers no matter what, and on other browsers only if you've mutated the string 'class' by appending a trim function, AND if that compatibility function was loaded sufficiently early in the HTML.
Thus it's safer to just use jQuery.trim(myinput)
Likewise with any other such basic operation.
The object system is horrible, the 'this' variable makes my head spin - it's almost impossible to know what object 'this' is in their event model.
Their 'undefined' and 'null' are insufficiently defined (AND you can override their definition!!).. You actually stupidly have to say
if (myvar) {.. } to truely/safely see if something is false. otherwise you'll mutate the variable! wtf???
Don't forget jQuery's fixing of on-page-load and timer screwyness.. IE/firefox also has massive memory-leaks with respect to dynamically assigned bind handlers, which jQuery fixes (albeit in painful ways).
Though in a system-language only timers would probably be relevant.
"jQuery (prototype, mootools, etc) solves shitty DOM implementations, not shitty Javascript implementations."
While that may be the primary/original goal, the browser-capabilities testing (of all libraries of this class) also extends to basic coding functions like string-utils - which are horribly incomplete in many browsers - and the fact that they differ on something so basic is mind boggling. To say nothing of trivial array/map operations.
With no feature-set testing capability coupled with the intent of handing off raw code to 3rd party virtual engines. With no 'reference' platform to validate code (with such simple things as which string functions are supported) and no useful error messages when making language library mistakes (nor any type-safety to determine it out of the box). And with respect to dynamicity, no equivalent 'perl -c foo.pl', 'use strict', or '-warn' pragma. No package namespaces. No legitimate mechanism of loading 3'rd party library files, much less a way of namespace collision resolution/isolation. No defined order of execution (some run in-line, others run on browser completely loaded, etc).
I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.
Sure a command-line javascript can define it's own standard and I'm confident that it can solve all these problems.. That's the great thing about standards - everybody's got one.
Well, you're talking extremes. In my humble experience, the main sources for bugs:
1) Inexperienced programmers 2) experienced programmers dealing with things they're inexperienced with (socket programming, DB programming, multi-threaded programming, external APIs, etc) 3) merging/adapting two or more unrelated libraries in ways the creators hadn't intended (e.g. hacks). This includes your OWN code - where 3'rd party linkages means you can't change the APIs 4) idiot-moments. Otherwise well-meaning code that was either dislexic (less than instead of greater-than or equals), pointer instead of reference, loosely-typed symbolic name mispelling (case mismatch in a hash-table lookup, etc). Things where looking back at your own code you just want to smack yourself.
1 can go to hell, Don't earn more than $30k / year until you fix this part. 2 is unavoidable - except that managers should be aware of the strengths of their coders and make sure that untested waters have explicit code-review / peer-review / pair-programming - or THEY shouldn't earn more than $30k/year 3 is really hard - though experience can help avoid certain inflexible API designs. Always make your APIs extensible (pass objects/messages instead of explicit parameters, don't make security lock downs too tight, etc). 4) is where language really comes in. If there are lots of syntax that look alike but do very different things, then language author should get a smack-on-the-back-of-the-head point. Side-effect programming is BAD. Languages that allow this are BAD. And while C is the mother of all side-effectors, perl and many symbolic languages are just as bad. The argument that it makes for more efficient code is BS because you can have adjacent syntactical constructs that produce the same assembly, but force to the casual reader the fact that something interesting is happening.
Simple retort.. Would anyone you know start a fresh project today with COBOL? If not, it's an antique. Though I do agree failure is a strong word - it probably served some useful role better than other languages of the day.. far be it from me to comprehend what that role was though. Hell, I'd rather have programmed in fortran - aspects of that acursed language still beat out C today.
I don't think you're right.. The intent in this language from TFA seemed to be to reduce the gap between a person that doesn't know how to code and someone able to do useful coding. And since this wasn't easily done in the past (such as COBOL), I imagine that there are major hurdles with producing a concise language that's intuitive to American Slang speakers. Increasing the verbosity doesn't increase clarity of code - the self-documenting feature you speak of. Is "for(int x =0; x < maxX; x++) {... }" any less readible than "loop from x until maxX step 1 begin... end." Once you've internalized the syntax (which IS the knowledge gap of casual/hobbiest would-be programmers), then this doesn't give you any greater understanding of what the code is doing.
DRAMATICALLY increase readability AND reduce bugs. But many such things can be handled by standardized libraries (even if they're only standard to the company you work for). Again, the ability to internalize the language is essential no matter what language it is, so I reject the notion of dumbing down a language purely to entice more comers. It only suits to insult those willing and able to internalize languages that are actually function/useful/productive.
To further your point. There is no such thing as free money.. Even if you have $50M in the bank, you don't necessarily have 'free money'.. There is something called the opportunity cost of holding money. And also a liquidity-demand curve. Namely, you can put that dollar into a CD, or commercial paper or a bond or whatever. And your CFO SHOULD be doing this with every penny the company has (with a tapering liquidity curve). So if you can borrow money cheaper than you can safely invest it, then you literally DO have to borrow $20k to buy that server, because that's the smartest thing you can do.
So lets say you use cash to buy the $20k equipment. That capital cost is not free. You have the traditional depreciation rate of the equipment (3yr, 5yr, 30yr, or whatever). But you STILL have the opportunity cost. Meaning what the next best investment strategy would have been... So if you have 5% yielding 6mo CDs. Then your cost is depreciation, operating costs (AC), hosting (rack rental, etc), inet share (if you can deterministically calculate IP-load as a fraction of total IP-BW), AND the interest you COULD have earned on every penny above (here, 5%), scaled out from the moment of purchase to a common maturity date. Further you have to take into account your personal liquidity-demand curve. You're fine with taking down [near]cash-reserves by say $100k for the quarter, but $150 means you'd have to start liquidating some short-term investments, and maybe the market isn't so great for liquidation right now (i.e. rising bond-rates, means loses on cashing out existing bonds). So maybe you should lease equipment for that last $60k (expensing $10k in lease fees).
So each purchasing decision needs to be coupled with the TOTAL ROI v.s. the next best alternative.. Which often is no-action, or in this case, leasing.
PARITY MUST DIE.. Seriously people, that's all I hear about in this thread.. Didn't you guys get the memo? Hard disks are large enough to not need disk-extension via RAID-5 (the ONLY advantage of RAID-5) for a vast majority of apps. I found some old RAID-5 SCSI configurations when I got to my current company.. We got a 20% speed-boost by switching it over to RAID-1 (granted the disk size cavitated). We did wind up quadrupling it's RAM, but that was cheaper than upgrading a single new SCSI disk. Yes RAID-5 is faster at reading, but I guarantee you that 64Gig of sys-RAM is faster than RAID-5 reads and RAID-1 is MUCH faster at random-writes than RAID-5 (though it does trail in linear-writes which is generally a non-issue).
That being said, there's little the dedicated-hardware can do that the good OS with lots of RAM can't do better (so long as you have enough parallel SATA connectors). Yes you can have battery-backup, but that's similar to UPS / machine (like google does). And when you enter multi-master clustering, then a good clustered OS RAID blows the pants off a SAN (granted, I'm not aware of such a currently 'good' system, but many theoretical ones are in the works).
Anyway, I'm making unsubstantiated claims, so feel free to embarrass me with benchmarks - I only have anecdotal evidence and theoretical purity.
lvm striping?? Where's the mdadm love??? It's so much more advanced (3-disk RAID-10, for example). When you've got 4Gig RAM and quad processing almost standard and 16-core with 64Gig on the cheap, where's the loss in performance due to SW raid?
Hell, I've got a mysql server with 32Gig of RAM with direct-IO so that non-app system-ram is used purely as a dirty disk spool (since fsync can return once one drive has the data). Ok, so that machine is using HW raid, but that's really only for hot-swap and 15-disk enclosure. My other machines (with only 4G RAM) have similar configurations but SW-RAID.
Hehe, the 3..5-way redundancy I recommended was primarily to address the peek probability moment of failure. Ideally you address this by using a completely different mechanism to avoid the probability swings. The most correct way of doing so is, as I recommending having fully electrically decoupled systems.
This means: 1) separate AC/DC converters for each power supply (you can often regulate DC voltages off a fluxuating AC source better than adjusting a DC voltage - well, unless you use some large step-down DC 2 DC voltage regulator, but I'm no expert in this industry just a punk orphaned undergrad in EE) 2) fiber-optic connectors to the RAID controller.
You could accomplish step 1 with eSATA, but I have no experience this with in a server configuration. Obviously more expensive server solutions exist.
I don't understand what your failure rate strategy is. First of all, there's no such thing as saying you are 90% or 10% of the way through a disk's life.. It's a probability distribution, who's probability is dramatically effected by the current events (and somewhat related to historical events). A drive might be at a 0.00005% probability of failure at any given moment, but then a large sustained read occurs which adjusts the heat and causes voltage fluctuations , so now you're operating at 0.001% probability.
Then a drive dies in hot-swap-mode, a drive spins down, then another spins up, this has massive voltage fluctuations as well as slight tension on the cabling which causes reflections in the wiring which increases your probability of failure to say 0.02%. (I'm totally making up numbers, but the trends are what's important).
So the act of powering down/up or hot-swaping intrinsically increases the probability of co-disk-failures, unless you have a very expensive system with separate AC/DC converters (e.g. fully decoupled) and obviously isolated frames, heat-compartments, etc.
BUT, you can mitigate this by having 3+-way redundancy (RAID-1; I honestly don't understand the point of using slower RAID-5 / RAID-6 anymore). So when one drive fails, you have addressed the probability of a second failure. There is a geometric reduction in probability that 3 or 4 or 5 simultaneous drives fail. Meaning even at the peek risky part of the drive-swap operation, if you have say 2% probability that another drive will fail, then there is 0.004% probability that two drives will fail simultaneously. 0.0008% that three fail, etc.
This isn't strictly correct, of course, because the probabilities are not fully independent. You have many common components, and thus their probabilities are intertwined. But sufficient to say the probabilities are less.
Now I say 3+way RAID-1 because it may be silly to swap out a single drive when one goes bad. The process I would recommend (if you have a sufficiently advanced RAID controller, and non-super-expensive disks), is this:
5-way RAID-1 with 2 powered down disks (thus effectively 3-way RAID-1) On a drive failure, power up the two disks and initiate their syncing. Swap out the error'd drive, and and initiate it's syncing.
For a brief-while, you have 2 valid, 2 semi-valid, and 1 semi-semi-valid drive.
As the drives sync-up(may take over 24 hours), power-down the original remaining 2 and remove them.
Recycle the good disks into JBOH (Just a bunch of hardware) clustering. Meaning boot-disks / log-file disks in say RAID-1, swapping out the oldest drive.
You can either buy several 4-way/5-way RAID controllers, or get a single 15-disk RAID controller for under than $1k. This allows you to have multiple logical volumes and share the 'spun-down disks', So now you're really only using 3 disks per logical-volume, though having two logical volumes with bad disks does reduce your ideal reliability somewhat. But this gives you 4 volumes which can be combined into RAID-10. You could build such a system for under $6k with various mixtures of high-end and low-end disks (for different partition requirements, boot/OS/linear-logging (RAID-1), random-write-data (RAID-10)).
If the data is super critical, use a block-level master-slave replication. Ideally your application supports direct master-slave or better yet, multi-master.
And if you're JBOH (Just a Bunch Of Hardware) clustering, then trivial RAID-1 with 2 or 3 disks (in software-raid) is all you need. Note, I use 3-disk RAID10 on my home linux machine, (that plus DVD drive fills up my IDE slots) - pretty clever technique. Yes I know virtually all MB's have hardware RAID these days, but unless they've got an extra 4Gig of buffer-RAM in them, they're pointless in my opinion, plus they're non-portable (screw transparent windows support, you can't distinguish disk errors from forced reboots anyway).
The closest I can imagine to this type of system working is an online system.
State-hub has server with 32k individually certified SSL connections. (meaning a man on a phone types in a key on one end, and another man on the phone types it in on the other end - if the keys match, the SSL connection is 'certified').
Those hubs cascade out as needed until all voting centers are accounted for.
ALL votes, in real-time propagate up to the local hub, which send aggregate data + signatures to parent hubs.
A group of voters is group-signed with physical voter-ids as having voted, and anonymous data containing the tally of votes.
Participants are required to wait until at least 16/32 or however many participants have completed (and thus the batch is committed in the hub). If there is a problem or voter-fraud, it's attended to there, the batch is invalidated (has a unique-id) and voting must resume (and legal proceedings begin).
All nodes keep full auditable records, and are cross-checked (local, printed barcode data, etc) against hub data. Several times (with paper data obviously taking a day or two to complete).
So here we have 3 simultaneous accounts of the vote. mater-data (only one that counts), site-data (on chip) and printed-data.
Even this still has several problems:
A) only semi-anonymous, you know that batch A had zero votes for candidate X, so you can infer that voter-Y voted a certain way (you of course don't store it, but the data is recorded and thus potentially hackable/exploitable) B) The machine itself can change the physical vote, but at least you can verify/audit/investigate the number of warm bodies that voted. C) You can DOS an election
Then you've replaced the paper ballot box with an electronic chip which can A) be lost B) be tampered with C) be replaced with a pre-created chip D) potentially have a virus which is injected into hub-machines E) Hub machines can be hacked directly, assigning results independent of the authenticated chips (e.g. dictator just claims the vote count with no basis in reality)
You're talking about the free rider problem. I'll give you a homework assignment. Consider 30 massive projects that had the free rider problem solved elegantly (without patents).
When you're finished, find 15 that didn't involve the government.
Give you a hint, society couldn't function without them.
Meaning, there are ways to get around free-rider without producing artificial scarcity. You just have to think hard, or convince society that they need to foot the bill for the greater good.
Patents allow you to not be clever, come up with mediocre ideas, and more-often-than-not detriment society.
Patents are evil, they should never have been added to our constitution. They serve no useful social role. Processes are what people come up with to get something useful done. They are not themselves the goal of any useful society or societal actor. The original (ill-conceived) intent of patents was to allow clever commoners to make a living by doing nothing but thinking things up. What this does is create artificial 'property' out of an otherwise unlimited resource (e.g. thought). Producing scarcity where none SHOULD exist.
So instead of negotiating price on prime real-estate. Or convincing somebody to give up their precious time to labor on your behalf, we instead have royalties, and more importantly, denial of service. Namely, I can prevent your innovation by strategically patenting random otherwise-useless things that I know can prevent you from accomplishing real work (that otherwise benefits society).
If I were strategically buying up land to prevent your rail-road, it would be the same thing.. Or if I were hiring the only people technically capable of doing your work (i.e. MS paying off big Linux gurus), then it would be the same thing. But, in those situations, we're dealing with real materials. IP is fictionally held ransom by the US founders. If we'd been founded 100 years before or 100 years later, we wouldn't have had IP. It's right up there with our funky archaic embeded masonic imagery.
Therefore suing for patent infringement is trolling. Constitution be dammned.
I think we're in general agreement, except that I think the chrome-OS goal is to treat ALL local data as cached or potentially cacheable server-data (i.e. google-gears). Then you're relying on the web-app vendor of your choice's backup strategies.
Though thinking it through, the big remaining issue is data-privacy.. It would be almost impossible to use a netbook in a eyes-off mode. Even if Google promised they wouldn't look at certain data, there's always the NSA or worse, china (I'm thinking global markets here).
Slashdot Mirror
How do you speculate that greenification reduces needed energy?
Consider that as man gets wealthier he wants:
A) Air conditioning
B) Lighting
C) transportation
D) electrical appliances.
We'll simply state that we're producing a generation (myself included) that's addicted to air-conditioning compared to even a preceding generation.
On the transportation front - we're talking about plugin hybrids as being the most practical 'green car'. In my opinion, that's a good thing, but it INCREASES energy demands, not decreases them.
Technically OIL is a geo-thermal byproduct, so it's as natural as steam-veins in iceland. So the question becomes whether non-coal/oil fired transportation is more efficient on the aggregate. I'll even assume, for sake of argument, the eventual treaties and technologies which support mobile CO2 sequestration.
In other words, in an apples to apples comparison, is wind (rare-earth allocations) + power-lines + metro battery storage + AC/DC conversion + LiIon storage (more rare-earth allocations) more efficient than local-motor oil burning?
I'm talking about efficiency based on Joules of energy; not dollars - which are affected by other factors.
There's a simple economic solution.. But first, the heart of the problem.
Nobody is allowed to know the exact reserves of Saudi-Arabia, though we have a decent idea about the rest of the world (at least in terms of active oil wells). So we're acting on a sort of desperate optimism. 'Of course they're plenty to be had'.. So speculation and hoarding isn't going on as it SHOULD.
If, on the other hand, we were able to release the information of current reserve readiness to the general public, then a count-down clock would effectively have started, and hoarding would go rampant.
This of course jacks the price of oil, and consequently hurts the world economy. But also massively increases spending in alternative energies.
You somewhat get the best of both worlds.. High oil prices with plenty of reserves.
Eventually alternatives succeed and oil futures decrease in value.. The fore-knowledge of this brings about the perfectly competitive market - such that efficient levels of R&D v.s. reward can find their way through.
Ahmadinejad is a liar, but in his religion, it is acceptable to lie to infidels.
However, I think you misrepresent/over-simplify his stated views on Israel. I listened painfully, to his interviews on his recent visit to the US/UN. (Sorry too lazy to look up quotes.)
But what he says is that:
If Nazi Germany committed a genocide, then why not graft land from Germany and give it to the Jews instead of taking land from the middle east?
Also, why weren't the Gypsies given their own land? They were equally persecuted.
Essentially, he reasons that the holocaust is not an excuse for the current situation.
Now his going-forward recommendations were to grant voting power to the residents (namely the Palistinians) and he presents the non-improbable outcome that they'd evict the Israeli's. So obviously this isn't going to happen, so he's not a pragmatist.
But the blanket assertion that he's crazy isn't the case, in my opinion.. He's carefully crafting diplomatic words that maximizes his position.
At the end of the day, we don't care about the history - in fact, the history of modern Israel is a lot more complex, and I don't even fully understand it - sufficient to say, the holocaust was not the most deciding factor. What we care about is that it's in our interests to have strong allies in the region. Look at teetering Christians African nations if you don't believe me.
How is only FF 3.5 supporting trim useful to designing a web page? You still have to wrap it in a function to support other browsers don't you?
Your turbo C analogy doesn't work because that is compile once deploy everywhere with no consequence.
The best you can say is that trim will be more efficient in FF 3.5 via the library. But with JIT becoming more common, you'd get that anyway in newer browsers.
== this
while reading the documentation on which object is passed as the this in various contexts may sound easy - What happens when you have 3 or 4 layers of abstraction that may or may not effectively swap out the this object such that a given function can not guarantee what fields/methods exist on the this object.
Maybe I'm just use to methods being tied to their associated class - being an old foggie. But Ive had a lot of bugs in jQuery callbacks because the this variable was of an unexpected source.
I understand your point about prototype vs deep C++ inheritance though. But neither C++, Java, Perl nor JS feel right to me wrt OOP. They all have serious code-clarity problems when you fully leverage their capabilities as anything more than glorified hash-maps / c-structs.
== truthiness
http://saladwithsteve.com/2008/02/javascript-undefined-vs-null.html
feels to me like bad design. What is the usefulness of all these possible combinations of truthiness? Perl had similar degrees of type cooersion to easily compare unrelated datatypes, but they at least all seemed obvious to me - the principle of least surprise / similar things look similar, different things look different. But JS type-coersion/truthiness doesn't minimize surprise to me. Here replacing undefined with an exists operator would do the trick. You dramatically reduce the number of combinations of truthiness at the expense of some code verbosity.
Granted there is one known edge case in perl that can prevent proper type cooersion for string concatenation, and there isn't an equivalent Number(), String() type-cast. But I'd only ever encountered it twice in my whole life.
No cache coherence so dont get your hopes up for general computing. though its probably not as bad as the PS3 chip with no virtual memory in the multi-core processing part.(forget the name.. aaaaarg)
Im not sure "separate computer" is accurate. you get copy on write performance benefits. So fork based processes would work like gang busters. Multi threading COULD work if they never modified common data pages. I'll just assume they have some kind of support for high performance mutexes.
What is worse is that theyve done away with cache coherence. So I dont think you can take a 48 thread mysql / java process and just scale it. You COULD use forked processes that don't share much. (ie postgres/apache/php).
"few people notice because all but the most recent implementations are resource hogs, and the most used API (the DOM) is hideous and causes aneurisms for multiplatform deployment"
Not quite sure where you're seeing people complaining about resources. Flash / java-applets still takes the cake there.
DOM isn't that bad. It's never been a problem for me. Though I prefer to concatenate an HTML string and set the innerHTML - but that's just me.
The offing of "aneurisms on multiplatform deployment", however is where I really take difference. How can the platform be legitimate if it doesn't work on anything but one version of one browser??? Thus you have to have if-statements for each browser (either explicitly or hidden via a library)??
Maybe you're use to being anally raped by "cross platform C/C++". But I've been spoiled over the past 20 years with standards at the language level and compensator's at the compiler level. (That or just using C for one targeted platform - which I know, makes me less of a Man; but the right-tool-for-the-job I always say)
For more, see my post above:
http://slashdot.org/comments.pl?sid=1462628&cid=30296518
Why does everybody keep mentioning DOM? wtf does that have to do with with any of the complaints I listed? In fact, I think the DOM implementation of most browsers is sufficient. Just don't muck with table DOM elements and you're fine. DOM is just one of several libraries javascript + browser provides.
.. }
My complaint is stupid things like:
myinput = myinput.trim();
can work on some browsers no matter what, and on other browsers only if you've mutated the string 'class' by appending a trim function, AND if that compatibility function was loaded sufficiently early in the HTML.
Thus it's safer to just use
jQuery.trim(myinput)
Likewise with any other such basic operation.
The object system is horrible, the 'this' variable makes my head spin - it's almost impossible to know what object 'this' is in their event model.
Their 'undefined' and 'null' are insufficiently defined (AND you can override their definition!!)..
You actually stupidly have to say
if (myvar) {
to truely/safely see if something is false. otherwise you'll mutate the variable! wtf???
Don't forget jQuery's fixing of on-page-load and timer screwyness.. IE/firefox also has massive memory-leaks with respect to dynamically assigned bind handlers, which jQuery fixes (albeit in painful ways).
Though in a system-language only timers would probably be relevant.
javascript + browser == necessary hurt
"jQuery (prototype, mootools, etc) solves shitty DOM implementations, not shitty Javascript implementations."
While that may be the primary/original goal, the browser-capabilities testing (of all libraries of this class) also extends to basic coding functions like string-utils - which are horribly incomplete in many browsers - and the fact that they differ on something so basic is mind boggling. To say nothing of trivial array/map operations.
With no feature-set testing capability coupled with the intent of handing off raw code to 3rd party virtual engines. With no 'reference' platform to validate code (with such simple things as which string functions are supported) and no useful error messages when making language library mistakes (nor any type-safety to determine it out of the box). And with respect to dynamicity, no equivalent 'perl -c foo.pl', 'use strict', or '-warn' pragma. No package namespaces. No legitimate mechanism of loading 3'rd party library files, much less a way of namespace collision resolution/isolation. No defined order of execution (some run in-line, others run on browser completely loaded, etc).
I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.
Sure a command-line javascript can define it's own standard and I'm confident that it can solve all these problems.. That's the great thing about standards - everybody's got one.
Well, you're talking extremes. In my humble experience, the main sources for bugs:
/year
1) Inexperienced programmers
2) experienced programmers dealing with things they're inexperienced with (socket programming, DB programming, multi-threaded programming, external APIs, etc)
3) merging/adapting two or more unrelated libraries in ways the creators hadn't intended (e.g. hacks). This includes your OWN code - where 3'rd party linkages means you can't change the APIs
4) idiot-moments. Otherwise well-meaning code that was either dislexic (less than instead of greater-than or equals), pointer instead of reference, loosely-typed symbolic name mispelling (case mismatch in a hash-table lookup, etc). Things where looking back at your own code you just want to smack yourself.
1 can go to hell, Don't earn more than $30k / year until you fix this part.
2 is unavoidable - except that managers should be aware of the strengths of their coders and make sure that untested waters have explicit code-review / peer-review / pair-programming - or THEY shouldn't earn more than $30k
3 is really hard - though experience can help avoid certain inflexible API designs. Always make your APIs extensible (pass objects/messages instead of explicit parameters, don't make security lock downs too tight, etc).
4) is where language really comes in. If there are lots of syntax that look alike but do very different things, then language author should get a smack-on-the-back-of-the-head point. Side-effect programming is BAD. Languages that allow this are BAD. And while C is the mother of all side-effectors, perl and many symbolic languages are just as bad. The argument that it makes for more efficient code is BS because you can have adjacent syntactical constructs that produce the same assembly, but force to the casual reader the fact that something interesting is happening.
Simple retort.. Would anyone you know start a fresh project today with COBOL? If not, it's an antique. Though I do agree failure is a strong word - it probably served some useful role better than other languages of the day.. far be it from me to comprehend what that role was though. Hell, I'd rather have programmed in fortran - aspects of that acursed language still beat out C today.
I don't think you're right.. The intent in this language from TFA seemed to be to reduce the gap between a person that doesn't know how to code and someone able to do useful coding. And since this wasn't easily done in the past (such as COBOL), I imagine that there are major hurdles with producing a concise language that's intuitive to American Slang speakers. Increasing the verbosity doesn't increase clarity of code - the self-documenting feature you speak of. Is "for(int x =0; x < maxX; x++) { ... }" any less readible than "loop from x until maxX step 1 begin ... end." Once you've internalized the syntax (which IS the knowledge gap of casual/hobbiest would-be programmers), then this doesn't give you any greater understanding of what the code is doing.
/\d{2}/ } map { $_[0] } @in;
Now built in expressive capabilities:
@out = sort { $a cmp $b } grep { $_ =~
or
set3 = set1.disjointSet(set2)
DRAMATICALLY increase readability AND reduce bugs. But many such things can be handled by standardized libraries (even if they're only standard to the company you work for). Again, the ability to internalize the language is essential no matter what language it is, so I reject the notion of dumbing down a language purely to entice more comers. It only suits to insult those willing and able to internalize languages that are actually function/useful/productive.
To further your point. There is no such thing as free money.. Even if you have $50M in the bank, you don't necessarily have 'free money'.. There is something called the opportunity cost of holding money. And also a liquidity-demand curve. Namely, you can put that dollar into a CD, or commercial paper or a bond or whatever. And your CFO SHOULD be doing this with every penny the company has (with a tapering liquidity curve). So if you can borrow money cheaper than you can safely invest it, then you literally DO have to borrow $20k to buy that server, because that's the smartest thing you can do.
So lets say you use cash to buy the $20k equipment. That capital cost is not free. You have the traditional depreciation rate of the equipment (3yr, 5yr, 30yr, or whatever). But you STILL have the opportunity cost. Meaning what the next best investment strategy would have been... So if you have 5% yielding 6mo CDs. Then your cost is depreciation, operating costs (AC), hosting (rack rental, etc), inet share (if you can deterministically calculate IP-load as a fraction of total IP-BW), AND the interest you COULD have earned on every penny above (here, 5%), scaled out from the moment of purchase to a common maturity date. Further you have to take into account your personal liquidity-demand curve. You're fine with taking down [near]cash-reserves by say $100k for the quarter, but $150 means you'd have to start liquidating some short-term investments, and maybe the market isn't so great for liquidation right now (i.e. rising bond-rates, means loses on cashing out existing bonds). So maybe you should lease equipment for that last $60k (expensing $10k in lease fees).
So each purchasing decision needs to be coupled with the TOTAL ROI v.s. the next best alternative.. Which often is no-action, or in this case, leasing.
PARITY MUST DIE.. Seriously people, that's all I hear about in this thread.. Didn't you guys get the memo? Hard disks are large enough to not need disk-extension via RAID-5 (the ONLY advantage of RAID-5) for a vast majority of apps. I found some old RAID-5 SCSI configurations when I got to my current company.. We got a 20% speed-boost by switching it over to RAID-1 (granted the disk size cavitated). We did wind up quadrupling it's RAM, but that was cheaper than upgrading a single new SCSI disk. Yes RAID-5 is faster at reading, but I guarantee you that 64Gig of sys-RAM is faster than RAID-5 reads and RAID-1 is MUCH faster at random-writes than RAID-5 (though it does trail in linear-writes which is generally a non-issue).
That being said, there's little the dedicated-hardware can do that the good OS with lots of RAM can't do better (so long as you have enough parallel SATA connectors). Yes you can have battery-backup, but that's similar to UPS / machine (like google does). And when you enter multi-master clustering, then a good clustered OS RAID blows the pants off a SAN (granted, I'm not aware of such a currently 'good' system, but many theoretical ones are in the works).
Anyway, I'm making unsubstantiated claims, so feel free to embarrass me with benchmarks - I only have anecdotal evidence and theoretical purity.
lvm striping?? Where's the mdadm love??? It's so much more advanced (3-disk RAID-10, for example). When you've got 4Gig RAM and quad processing almost standard and 16-core with 64Gig on the cheap, where's the loss in performance due to SW raid?
Hell, I've got a mysql server with 32Gig of RAM with direct-IO so that non-app system-ram is used purely as a dirty disk spool (since fsync can return once one drive has the data). Ok, so that machine is using HW raid, but that's really only for hot-swap and 15-disk enclosure. My other machines (with only 4G RAM) have similar configurations but SW-RAID.
Hehe, the 3..5-way redundancy I recommended was primarily to address the peek probability moment of failure. Ideally you address this by using a completely different mechanism to avoid the probability swings. The most correct way of doing so is, as I recommending having fully electrically decoupled systems.
This means:
1) separate AC/DC converters for each power supply (you can often regulate DC voltages off a fluxuating AC source better than adjusting a DC voltage - well, unless you use some large step-down DC 2 DC voltage regulator, but I'm no expert in this industry just a punk orphaned undergrad in EE)
2) fiber-optic connectors to the RAID controller.
You could accomplish step 1 with eSATA, but I have no experience this with in a server configuration. Obviously more expensive server solutions exist.
I don't understand what your failure rate strategy is. First of all, there's no such thing as saying you are 90% or 10% of the way through a disk's life.. It's a probability distribution, who's probability is dramatically effected by the current events (and somewhat related to historical events). A drive might be at a 0.00005% probability of failure at any given moment, but then a large sustained read occurs which adjusts the heat and causes voltage fluctuations , so now you're operating at 0.001% probability.
Then a drive dies in hot-swap-mode, a drive spins down, then another spins up, this has massive voltage fluctuations as well as slight tension on the cabling which causes reflections in the wiring which increases your probability of failure to say 0.02%. (I'm totally making up numbers, but the trends are what's important).
So the act of powering down/up or hot-swaping intrinsically increases the probability of co-disk-failures, unless you have a very expensive system with separate AC/DC converters (e.g. fully decoupled) and obviously isolated frames, heat-compartments, etc.
BUT, you can mitigate this by having 3+-way redundancy (RAID-1; I honestly don't understand the point of using slower RAID-5 / RAID-6 anymore). So when one drive fails, you have addressed the probability of a second failure. There is a geometric reduction in probability that 3 or 4 or 5 simultaneous drives fail. Meaning even at the peek risky part of the drive-swap operation, if you have say 2% probability that another drive will fail, then there is 0.004% probability that two drives will fail simultaneously. 0.0008% that three fail, etc.
This isn't strictly correct, of course, because the probabilities are not fully independent. You have many common components, and thus their probabilities are intertwined. But sufficient to say the probabilities are less.
Now I say 3+way RAID-1 because it may be silly to swap out a single drive when one goes bad. The process I would recommend (if you have a sufficiently advanced RAID controller, and non-super-expensive disks), is this:
5-way RAID-1 with 2 powered down disks (thus effectively 3-way RAID-1)
On a drive failure, power up the two disks and initiate their syncing.
Swap out the error'd drive, and and initiate it's syncing.
For a brief-while, you have 2 valid, 2 semi-valid, and 1 semi-semi-valid drive.
As the drives sync-up(may take over 24 hours), power-down the original remaining 2 and remove them.
Recycle the good disks into JBOH (Just a bunch of hardware) clustering. Meaning boot-disks / log-file disks in say RAID-1, swapping out the oldest drive.
You can either buy several 4-way/5-way RAID controllers, or get a single 15-disk RAID controller for under than $1k. This allows you to have multiple logical volumes and share the 'spun-down disks', So now you're really only using 3 disks per logical-volume, though having two logical volumes with bad disks does reduce your ideal reliability somewhat. But this gives you 4 volumes which can be combined into RAID-10. You could build such a system for under $6k with various mixtures of high-end and low-end disks (for different partition requirements, boot/OS/linear-logging (RAID-1), random-write-data (RAID-10)).
If the data is super critical, use a block-level master-slave replication. Ideally your application supports direct master-slave or better yet, multi-master.
And if you're JBOH (Just a Bunch Of Hardware) clustering, then trivial RAID-1 with 2 or 3 disks (in software-raid) is all you need. Note, I use 3-disk RAID10 on my home linux machine, (that plus DVD drive fills up my IDE slots) - pretty clever technique. Yes I know virtually all MB's have hardware RAID these days, but unless they've got an extra 4Gig of buffer-RAM in them, they're pointless in my opinion, plus they're non-portable (screw transparent windows support, you can't distinguish disk errors from forced reboots anyway).
The closest I can imagine to this type of system working is an online system.
State-hub has server with 32k individually certified SSL connections. (meaning a man on a phone types in a key on one end, and another man on the phone types it in on the other end - if the keys match, the SSL connection is 'certified').
Those hubs cascade out as needed until all voting centers are accounted for.
ALL votes, in real-time propagate up to the local hub, which send aggregate data + signatures to parent hubs.
A group of voters is group-signed with physical voter-ids as having voted, and anonymous data containing the tally of votes.
Participants are required to wait until at least 16/32 or however many participants have completed (and thus the batch is committed in the hub).
If there is a problem or voter-fraud, it's attended to there, the batch is invalidated (has a unique-id) and voting must resume (and legal proceedings begin).
All nodes keep full auditable records, and are cross-checked (local, printed barcode data, etc) against hub data. Several times (with paper data obviously taking a day or two to complete).
So here we have 3 simultaneous accounts of the vote. mater-data (only one that counts), site-data (on chip) and printed-data.
Even this still has several problems:
A) only semi-anonymous, you know that batch A had zero votes for candidate X, so you can infer that voter-Y voted a certain way (you of course don't store it, but the data is recorded and thus potentially hackable/exploitable)
B) The machine itself can change the physical vote, but at least you can verify/audit/investigate the number of warm bodies that voted.
C) You can DOS an election
Then you've replaced the paper ballot box with an electronic chip which can
A) be lost
B) be tampered with
C) be replaced with a pre-created chip
D) potentially have a virus which is injected into hub-machines
E) Hub machines can be hacked directly, assigning results independent of the authenticated chips (e.g. dictator just claims the vote count with no basis in reality)
You're talking about the free rider problem.
I'll give you a homework assignment. Consider 30 massive projects that had the free rider problem solved elegantly (without patents).
When you're finished, find 15 that didn't involve the government.
Give you a hint, society couldn't function without them.
Meaning, there are ways to get around free-rider without producing artificial scarcity. You just have to think hard, or convince society that they need to foot the bill for the greater good.
Patents allow you to not be clever, come up with mediocre ideas, and more-often-than-not detriment society.
Patents are evil, they should never have been added to our constitution. They serve no useful social role. Processes are what people come up with to get something useful done. They are not themselves the goal of any useful society or societal actor. The original (ill-conceived) intent of patents was to allow clever commoners to make a living by doing nothing but thinking things up. What this does is create artificial 'property' out of an otherwise unlimited resource (e.g. thought). Producing scarcity where none SHOULD exist.
So instead of negotiating price on prime real-estate. Or convincing somebody to give up their precious time to labor on your behalf, we instead have royalties, and more importantly, denial of service. Namely, I can prevent your innovation by strategically patenting random otherwise-useless things that I know can prevent you from accomplishing real work (that otherwise benefits society).
If I were strategically buying up land to prevent your rail-road, it would be the same thing.. Or if I were hiring the only people technically capable of doing your work (i.e. MS paying off big Linux gurus), then it would be the same thing. But, in those situations, we're dealing with real materials. IP is fictionally held ransom by the US founders. If we'd been founded 100 years before or 100 years later, we wouldn't have had IP. It's right up there with our funky archaic embeded masonic imagery.
Therefore suing for patent infringement is trolling. Constitution be dammned.
I think we're in general agreement, except that I think the chrome-OS goal is to treat ALL local data as cached or potentially cacheable server-data (i.e. google-gears). Then you're relying on the web-app vendor of your choice's backup strategies.
Though thinking it through, the big remaining issue is data-privacy.. It would be almost impossible to use a netbook in a eyes-off mode. Even if Google promised they wouldn't look at certain data, there's always the NSA or worse, china (I'm thinking global markets here).