I'm sure that exponential feedback systems are to blame here... Nature is all about such systems. We are segregated in our skill sets (both intra-species and extra-species) I believe mostly because of these feedback systems... If you "happen" to do well with a task, your body latches on to it irrationally.. Which focuses your mind and attention towards this task.. You beat at it against all subsequent failure.. Your first impression was that of attachment.. You are destined to become an expert one day (even if only a poor one).
Conversely, if your experiences are negatively received, then you will have a distaste and a self-distracting clumsiness on the topic.. Continuously re-inforcing your ego that this is not for you.
Balance, for example is a prime athletic skill... If you have it, you have a tremendous range of abilities. You can be a risk taker because you 'irrationally' trust that your body can move the way you envision it to.. In fact, you don't even always plan out your path... You trust (from history) that you'll figure it out as you go. And sure enough, most of the time your body will silently surprise you. But a clumsy person will impeed in their ability to take on even the most basic walking, turning, backing-up skills.. Fearing any irregular course of action without a fully thought out plan.. Visibly seeing all the potential pit-falls, and blindly letting them happen (almost seaking them out.. exaggerting sometimes when with an audience).
So when you are in your attached element (beit math, music, art, literature, etc), your mind provides the appropriate positive feedback that glides you effortlessly along - enhancing your skill-set. And the more bredth in a topic you have, the fewer empediments (especially in math).. Without exception, those that I've seen that do well in math classes had a tremendous amount of extra-carricular knowledge on the topic.. Those that did poorly, could be found to be poor at many of the fundamentals of math. Likewise with computer science. (Two topics on which I have reguarly tutored)
These could be used to implement very fast message passing between threads (process some data, store it somewhere, then atomically write the address to the end of a queue) with no need to perform a system call (which meant no saving and loading of the CPU state, just jumping cheaply into a mode that could access a few more registers).
I'm confused, why would you need a system command to pass messages between threads? Isn't that what atomic read-and-write ASM commands are for? That plus thread-shared memory? I have a foggy memory of the alpha instruction set, but other than perhaps a more sophisticated cache-locking, I don't see what they could have that was more innovative for message passing.
I would say that most threaded message passing these days have significantly more overhead. So aside from certain single-function high performance applications, I don't see much advantage to these techniques anymore. You've got apache and mem-mapped shared-memory segments for worker allocation management.. You've got similar environments under postgres (using ID oriented shared-memory segments and semephores).. You've got mysql with multi-threaded shared memory (and likely with atomic read-write mutex's). All of these are using well defined C multi-threading models that - other than setup - don't require OS commands.. Granted a c-library mutex might call a yield system command if the local spin-lock-loop runs too long. But you can't get around that without a change in the core application's algorithm.
Or am I missing something related to VM implementation?
They don't know good writing -- as the great producers of the past did. I disagree.. Movies parallel the music industry.. In that industry I am aware of scouts which are looking for a formula. They have investigated very deeply the trends in music that sell and don't sell - they regurgitate that formula in most any new work that gets taken on and promoted.
It's also interesting that the formula is self-fullfilling.. Repetition of a genre produces a tolerance and then a taste for it.. Which facilitates more profit via repetition.
I'm sure a lot of this applies to script selection... Don't make it too complicated, too deep or too emotional, because you scare off a large audience.. Which then produces an audience devoid of depth, which would not be able to accept a deep/complex movie in the future. And even screen plays that are complex can often be edited down.
Also, as you can dramatically see in popular books that have become movies, the focus of the screen-writer can dramatically alter what the reader/watcher experiences (almost always for the worse).
While that's really cool and all.. I wonder if that generalization doesn't reduce the flexibility of clustering methods. I can only assume that somewhere it is configured how the machines interact. UNIX used good ole 'rsh hostname command | output' which seems to fullfill the same requirements. UNIX had many tools which were designed to be character stream oriented (cpio, tar, sed, grep) which faciliated this cross-hosting capability. But today, you have to decide whether you're using ssh and whether you're zipping the stream (which algorithm), encrypting the stream (with what algorithm), using which authentication method, etc. It's very nice to be able to rsync -e 'ssh -C' path1 host:/path2
I'm just saying, while I agree the everything-is-a-file is cool and all, I've found that flexibile configuration is essential.
So it is ok for the founding fathers to stop their government from abusing its power, but it is not all right for us?
Well, yes and no.. Of course any existing power-base is going to demonize revolution as an evil and misguided minority... The "revolutionaries" are necessarily to be sacrificed. If it wasn't sacrifice, then it wouldn't be worth "revolting" e.g. going to war over.
The trick is that you're not likely to have any sort of organization in any potential revolt, as the establishment is successful specifically because it can maintain it's current laws and order [of power structure]. Nothing wrong with that mind you.. Just that the founding fathers' presented sense of civic duty was not something that can easily be attained from the computer desk (modern version of the arm chair).
This is an excellent post and it reflects my perspective very well. But I would add one thing. The value in bio-technology is going to come, not in problem-solving, or geneticlly engineered algorithms, but in fault-tolerance... Which I believe was stated in the article blurb (sorry, haven't read the article).
Currently, when you want redundancy, you have to build 100% replicas, do 100% redundant computation, then have heart-beat monitors which take down failing nodes and notify a human to handle the failure.
You can engineer probable points of failure and only make those aspects redundant to reduce the cost of the overall system. But the problem with that approach is that every component is potentially faulty to some degree (given enough time).
Let my preface by saying IANA Biologist
My understanding of how the brain works is that every system (neuron, etc) has a deminishing degree of redundancy the furthery away from the currently active node. Every neuron has a decreasing (but existance) participation in every action of every other neuron.. By existing, I mean, once out of every hundred million fires, you might fire on behalf of some other neuron. This (in my understanding) is due to the massive farming out of dentrite-trees which provide voltage to most other neurons and thus provide a certain non-zero probability of a non-related neuron in fireing as part of the action tree.
Presumably the value in having this mass participation is that other neurons are reguarly "included" in the decision making process and thus can take over when the neuron gets tired (e.g. when staying up VERY late and having major centers of the brain slowly shut down, but still pulling an all nighter and thus need some cognitive capability).
To engineer a system with this degree of multi-specializated worker nodes, but with the ability to randomly share code between nodes and to occasionally take over (possibly to facilitate heavy loads, but more importantly to handle fail-over gracefully) is what I think is most valueable in such research.
Unless you are doing simulations or rendering or something I just can't see the minor increase as worth it.
I agree with your post, but this part stuck out. Why is it, that on a slashdot geek site, nobody ever references CPU performance to programming desktop/work-station use. Photoshop, servers and games seem to be the main reasons people justify the highest-performance machines. But ever since I was in high-school (in the 80s), I've always overtaxed my machine... I've never had a machine and said "for what I do, this is sufficient".. And it never mattered what it was I was doing.. Beit running windows (in the 90s) and experiencing the dreaded context-switch pause... Beit Linux and running evolution + spam-filtering + "grep -r" on something - I've always gone "man It sucks working on this machine at work, v.s. the machine I have at home collecting dust". And my work machine has never been a slouch (currently a AMD 2800+ Barton with 1.5Gig of RAM).
Now if a linux programmer uses vi all day and ssh's to a beefy build-machine, then I can understand them not needing a beefier desktop/work-station. But I use to use xemacs and THAT was slow on many machine in the late 90s. Now I use a java editor named idea (commercial counterpart to eclipse) and every ounce of horse-power I can muster I long for. With intelligent real-time code analysis, there is no longer such a thing as idle-time on the work-station. Then add the fact that you can put your application server on your desktop, along with a full project-management suite (evolution, time-tracking tools, dozens of terminal windows, dozens of browser windows...). Waiting 20 seconds for the mouse to regain focus because I'm deploying a new application is just painful. Now do this 5 times in quick succession because you're iteratively debugging something.. Multi-CPU is a god-send for this type of environment.
My point is that I almost never hear people referencing this type of multi-application work-environment as a justification for cheap-but-beefy machines (except for the ubiquitous reference to photoshop, which can kiss my *@@).
That's not the correct way to be doing things, anyway. Try this instead
You missed the part where I compared it to cooperative multi-tasking.. You are wrapping the collection at constructor time, BUT half (and I do mean half) of the time you don't have control over the constructor to an object.. Especially if you are writing middle-ware code, which is most of what Java does - at least good application designs write most of their code in the form of middle-ware.
Take Sort for example... It can't depend on the fact that even though it asks for a generified collection that there is any sort of type-safety involved.. The only thing it can do is pre-validate the data-type of the existing items in the collection that is passed to it. But that's a performance hit, and the ONLY thing that this will do is produce a more meaningful runtime exception.. i.e. instead of an exception in the comparator you get one in the sorter with an explicit "element in collection of type X was really Y" RuntimeException.
Caches, Marshellers / Serializers, IPC services, persistence sercies, etc. They all are middleware applications which throw really really confusing errors sometimes because they aren't passed the expected classes. And when I say confusing, I mean they don't often throw class-cast exceptions, but instead meta-data mismatch exceptions.. But that leads you to believe that you've missed an attribute in the XML configuration instead of the fact that you've adding an object of the wrong type to the middle-layer.
Ideally, generics would be fully enforced by the VM. What we currently have (even with the spettering of Collections.unmodifiable,synchronized,checked etc are weak-enforcement which at best provides spot cleanness of code.. But any static anylizer tool could have detected innappropriate local bugs.. The more critical bugs are inter-moule bugs. And APIs of that sort tend to be littered with innappropriate parameter-checking. If you don't think this is a problem, then what is the number 1 security loop-hole in most older C libraries? gets(). This function (for performance purposes) didn't verify the size of the string so it allowed the over-flowing of the buffer and overwriting of user-space memory. Most other languages handle strings in a less performant, but more robust manner, so this type of bug has mostly dissapeared.
In java, with the advent of dynamic proxies and aspect-oriented-programming, the situation is even worse, because inter-module libraries can proxy objects which don't even match the appropriate prototype/interface. So you actually wouldn't get a class-cast-exception, but instead an arbitrary exception (most likely an NPE) inside the InvocationHandler.
This is mostly a rant, but it's based on my growing frustration with the lack of type-safety in java frameworks... Yes, you're certainly free to not use those frameworks.. But with the increasing movement into container-managed services (tomcat, jboss, or even spring/pico-container), this type-looseness is becoming a growing problem.
You can't cheat the java type system. You're kidding right.
Bar b = new Bar(); Foo f = (Foo)(Object)b;
Works just fine for me... Until you get the ClassCast Runtime Exception.
Now you might call this a contrived example.. Except that it's not.
How many thousands of function calls take Serializable or worse "Object" as a parameter? Virtually every IPC related activity does at some point. That includes all of j2ee, which are considered "enterprise" level coding frameworks.
Generics was a step in the right direction with compile-time enforcement of "many" of these opaque "Object" APIs.. But It definitely didn't penetrate some of the more important areas; just collections (which was at least the most [mis]used form of generalized types).
But Generics doesn't have any means of enforcement.
Collection myFoos = new ArrayList(); Collection myUnsafeFoos = myFoos; Bar bar; myUnsafeFoos.add(bar); Foo foo = myFoos.iterate().next();
will throw a ClassCast Runtime Exception.
Now it's semi-trivial to write collections to enforce type-safety (just like synchornization).. But this is as effective as cooperative multi-tasking was in the 90's at reducing bugs.
Java has a lot of historical baggage that keeps it from being a refined and bug-resistant language.. And the proliferation of XML-configured reflective programming is really getting out of hand. That being said, I am not aware of any other development platform that is as versatile..NET had a triffle of potential (being a rewrite of Java), except that it's got Big [Corporate] Brother to keep it from reaching it's full potential.
So far as living to a ripe old age just 'cos your great-grandaddy did? Don't forget, they didn't have McDonalds to deal with.
You forgot to mention the probability that you will or will not get the gene(s) that let him live to that ripe old age. You could take after your fahter in every way except age expectancy. Especially if the gene is recessive.
So yeah, gene-screening is much more effective I would guess.
The person you are today is an echo of your ancestors and his decisions.
So does that mean you dishonor the 4 billion ancestors that you've forgotten about? While I'm ignorant of ancestrial worship/honoring, I suspect that it's only the ancestors that were famous that people tend to honor (including directly remembered relatives).
I think they should test the subjects general multi-tasking ability and come up with a statistic that correlates multi-taskability (or inability) to accident+phone rates.
But the same could be said about alcohol-inhibition. I've been in the unfortunate situation of needing to drive a few blocks home after having a couple too many drinks... But during this period my adrenaline is pumping because I've ingrown the danger of doing that exact act. I'm sure the shortness of the action allows the adrenalin to compensate..
But the importance is that there is no way of enforcing mental competence.
I don't know about other people.. But my motivation for Open Source contributions have to do with a deeply rooted need for modularity.. Since a child I've been of the opinion that (with a certain cutoff) you should always take the more difficult road; to spend more time now so you don't have to perform repetative tasks later. In video-gameplay, it means spend more on resources (hoping you can fend off early invasion) such that you have greater available resources in the future.. In programming, it means set up reuseable modules or enhanced the capabilities of a module such that it can be used more generally and for more purposes. In terms of projects, it means break the project up into completely isolated and independent functional units which can be used for alternate unrelated projects. In terms of problem solving, it means encapsulate the ideas in such a way that if I move from company to company, I don't have to re-invent the wheel when I come across similar projects (unfortunately there are legal restrictions as to how far I can take this path).
Thankfully my last couple employers were big advocates of OSS, so I was able to take this problem-solving mentality to the level of open-source modules (in perl and java).
So for me, it's not about the love of the OSS process (though that's there).. It's not about giving back to a community from which I so heavily borrow (that's there too). It's not about volunteerism or community service (which a majority of Americans take part in for tasks in whicih they consider hobbies... cleanup, building structures, food-drives, telethons, religious prosecution). It's about pure self-interest... Adam Smith would be proud. My self interest is the need to carry a problem solution outside the borders of a company that could lay me off at ay moment.
Wasn't the new testament based on the teachings of a Jewish Communist?
While I love the idea of what you said, unfortunately it doesn't hold water.. A good communist would be at odds with the government.. They would want to maintain as much self-governance as possible (Waco Texas, etc). That Jew was quoted as saying render unto Ceaser that which is Ceaser's.
He also wasn't much of an economist, so we shouldn't follow his economic example. If we all gave up our possessions and roamed the forests picking fruit from other people's lands on Saturdays so we could perform full time proselytizing, then we'd have a free-rider problem - nobody would cultivate the fruits (nor have the capital to invest in next years crops), and thus we'd all starve after the first season.
I hadn't read the article, so I missed the fact that it was a man in the middle attack. But that doesn't obviate the need for securing the authentication process to facilitate public trust. Again, I recognize that IRC is limited to what it can support in terms of authentication (similar to telnet).. But I did want to mention that you don't need public key authentication.. HTTP and IMAP (and I assume POP), for example supports client digested passwords (e.g. they are never transmitted). I believe the protocol they support would use the same salt for every login attempt (login + realm + password), so a man-in-the-middle could capture and replay the digested result as easily as for clear-text.. The difference being, you could only use the captured results for the same user + realm + password combination (which presumably is semi-unique across the internet, at least as far as useful attacks go). So now you have digested passwords stored on disk, and digested passwords transmitted across the network (SSL'd or not) and only the login user knows his password.
Again, something like telnet is incredibly limited, but IRC has a specific client, so one would imagine that over the years digested authentication would have been added to the protocol.
My main beef is that I know for a fact that way too many highly sensitive institutions still store passwords in clear text (and encrypting them is as bad as clear-text). I know this is the case because if you go to any web site's "forgot password" section.. If it asks you for your mother's maiden name, the site has two strikes against it.. One is identity-theft (almost as bad as asking for your SSN), and the other is the fact that it seems to care about who you are because it's obviously about to disclose sensitive information to you.. A correct design doesn't HAVE any sensitive information.. A simple "I'll send a message to your cell phone, email, physical-mailing address, transfer money TO your established bank account/credit-card (as does paypal or conversely for USPS)".. Anything where a previously established external form of trust exists. And most importantly the message is a reset of a password, not the original (as that would prove that a clear-text password exists)
I'm not a big browser of IRC's, but do we honestly still use clear text passwords anywhere? I mean unless IRC is such an old service that it can't make use of any of the dozen some odd technologies that have been standardized on in the past 20 years.. come on!!
Who yearns for a time when everything is out of your control and sailing sticks across a pond is fun because you've still to undeveloped mentally to enjoy a good game of Risk?
Risk? I have an 8 year old niece who plays risk.. Come on, Axis and Allies!!
Why wasn't the whole stack written in perl? Ok, what about SQL.. That's not even JIT'd. What about about the startup process.. Why isn't that compiled directly into the kernel? Boot-up-times could be insanely fast.. Hell, you could even embed the mysql and apache and slash-code directly as a kernel module (a la tux)... You could have slashOS.
Obviously separation-of-concerns plays a role in these decisions.. But more importantly is the UNIX mentality of tool-boxing. Each language performs a single role (ideally) and each module is built out of the most appropriate tools (including language).
If 90% of the "Thinking" goes into the web request and the database reconciliation, and those aspects of thought are VERY uniform and consistent across all applications, then they BELONG as raw mathmatical code (e.g. c or pascal or take your pick beyond my expertise). Since there is no varyance, there is no benifit in JITing them every time they launch. Incidently if apache or Mysql were done in Java (i.e. hsqldb and tomcat), I doubt there would have been any performance hit, as both apache/mysql are services which have long live-runs, so load and JIT time are neglegable compared to boot-time.
The thing that should be scripted is what is most highly deviating between deployments.. Obviously shell-script being the most crude of the available languages (perhaps surpased by the non-Linux VB-Script), or maybe PHP (which I know many sys-admins who do shell scripts via PHP).
Perl is a fullly featured language (and if you don't believe me, try comparing it to bash and try to escape every possible string, and get back to me). This fact makes perl better than AWK, SED, grep or [ba]sh to do full system programming... Now I would argue that perl doesn't scale well into large projects (code-management wise).. It's harder than C to anylize since almost everythign is symbolic and has side-effects (the fact that whether you last referenced a scalar as a string or integer affects what it does when you concatenate is a big element-of-surprise when performing data-encapsulation). But single-focused applications like bugzilla or even slash-code are perfectly fine to write as perl applications.. You don't have unrelated application-level modules being brought together (meaning while IO::File is a module, it's purpose is to be reused, whereas bugzilla-preference-manager is not meant to be used for anything other than bugzilla... But the author is forced to be aware of the bugzilla-list-bugs module).
With Java and.NET (and I'm sure other languages), it's hard to write un-anylizeable code (though with the advent of XML and xdoclet it's getting easier). Note that I didn't say unreadible or unmaintainable.. In Perl you can load a module which forcibly redefines many of your functions.. This is not only feasible, it's common practice.. Now "good practices" says a module should use cooperative symbol injection (meaning the caller asks for symbols to override). In C++ you scatter the definition of your methods throughout many classes using the a::b::c syntax to pull them all together.. Convention reduces the propensity to abuse this, but it's still common practice to use include-file magic to completely alter which methods are compiled in. Java does use reflection and proxies more and more, which are just as bad (and often uses XML to define when/where/how to use such proxies). But this at least only provides "deviations" away from the base code; and more importantly is similar in effect to generalization-specialization... Since OOP often has you over-riding methods, reflection is more like dynamicly coded specialization. So it's no more inelegant than multiple overrides which OOP commonly allows (not aware of all the implementations of OOP)... Of course, you could always choose to say OOP should only ever specialize each method exactly once.
Someone else's comment about google spread sheets being butt-slow is not an issue of throughput, but latency (both being elements of
Don't forget that, for many years, the USA have been at the forefront of technology and science because the US Governement -- meaning you, Happy American Tax-Payers!
And AT&T was at the fore-front of technology for many years (i.e. Bell Labs). And the robber barons were great philanthropic institutions. The problem is that when you have "excess", it doesn't take a whole lot of brain power to say "maybe some of this could be diverted to research to better suite our future".. It isn't that you're sacrificing anything, but trying to diversify your wealth.
During WWII, the atomic bomb was part of the same excess that we spent on just about all engineering feats during that time.. It was just one of many extremely over-funded projects. Likewise in Germany. The wealth was the pre-allocation of massive funding due to higher taxation and rationed resources. Somewhat similar during the appollo missions (for the cold war).
The reason we're seeing scientific contraction in the US government today is due to the contraction of funds (and thereby the excesses). Republicans are trying to remove the entitlement society that built up over the years.. They're trying to minimize the economic impact of the fully understood environmental issues. Granted, they're minimizing this for their coffers / financial backers. They're doing so by "stalling", by "rhetoric", and in some cases, by outright lieing. This works because most Americans are largely detached from political intricacies - and are instead moved by talking-points. It works because many Americans are deluded into believing that what's best for the 1% is best for them.
The "excess" funding in the military is now being spent on a hot-war. The "need" for NASA has contracted dramatically since the decline of the space-race in the 80's. The NSA is mostly just a commoditized "google" for telephones networks now - most technologies are already in place.
I'd say you are both missing something critical... Context. Firearm means the same in MA as it does in Florida, both to citizens and to the law.. The difference is context. If a lawyer in MA says to the judge or jury "this violates the firearm law XX", there is implicit context of "in this state".. To clearify context, the lawyer might say to the judge or jury "while the victim was in Delaware, he was in violation of the Delaware firearm law YY".
It's exactly the same as a local variable, local object, verses a global variable/object.. The context is often time implicit, and often times requires qualification.
In a programming language, we say "this is a keyword", or "this class extends that class".. But without knowning the particular programming language, those phrases may not have enough meaning.. A keyword in Lisp might have a completely different meaning than one in "c".
You have protocol overhead too of course; 300k 'real' download speed is consistant with a 384k, burstable to 768k, circuit.
I doubt it, though you may know something that I don't. Constellation-chart modems are throughput machines. If you wanted to send a character, then flush the queue, then send another character, then yeah, your sustained is going to absolutely suck, because each chirp you send through is only partially filled.. Especially if you're wrapping each character with a TCP/IP packet. But when you're using throughput testers, you're sending raw contiguous bytes of data with almost no flushing.. Latency is foregone for throughput. Such a thing makes IP and ECC based modulation/demodulation sing (e.g. minimizing the overhead).
Most physical-layer networking architectures that I am aware of scale pretty well in the presense of high contiguous bandwidth users. Latency starts sucking as you add users, but packets and line-ownership times are optimized to send large large chunks at a time (especially considering that a latent sender will have backlogged a large chunk to send). In Ethernet all senders wait until the line is free before initiating a transfer. In token ring, you are given a time-share of those wanting transmission time. T1 and OC1 have various guaranteed bandwith allocations. Full duplex modems don't have collision issues if I recall. I assume DSL is the same (sender and receiver use entirely different frequency ranges, so there is no collision). I don't know what coaxial cable internet uses, but I assume it's similar to cell-phone based technologies (TDMA, CDMA, etc). Collisions (and thereby error detection/correction, resending) arguably play a greater role there.
However, if lowering subscription level in DSL lowers bandwidth, then I highly doubt that the hardware has ANYTHING to do with it.
I would say that VB is to windows what bash/perl/Tk is to UNIX. The things that the two OSes wind up doing the most can be handled by VB or perl respectively.. VB has an excellent form-management editor so it blows away perl/Tk. I didn't realize that VB compiled down to assembly, but I highly doubt that that matters any, as most assembly probably only delegates to VB core libraries. The fact that you can probably optimize a (pseudo code)
for x in 1 to 100
tot *= x end for
to raw assembly probably does not affect 99% of the code that is generated for a VB app. Perl, on the other hand doesn't have the assembly option.. The closest I ever saw was something that wrote out c-code to render the AST - thereby skipping the parser stage. I was under the impression that VB compilation was merely a tokenizer (similar to python). In perl all variables are advanced objects which can type-cast on the fly (and keep caches of previous type castings in case they flip flop back and forth, say between a string, an int and a double). I recall VB having similar opaqueness (though I also recal that you can designate more stringent data-types). The effect is that the simple 'total = total operator varable' is not going to translate directly into assembly code very nicely.. Especially if the language can support side-effects in variable assignment (perl is notoriuos for this.. They even call it a reference's 'magic' setting).
I've seen people comment that.NET might be undesireable because it's interpreted. For the above arguments (that much of VB/perl type languages are nothing more than delegators), that's largerly a moot point. Especially since the interpretedness of java/.NET faclitates a JIT.. You can consolidate all the byte-code of an entire custom-extended core-library (such as Map), and have it become more highly performant than say writing a 'magic' enhancement to the core reg-ex engine of VB or perl, which will never get faster than the sum of it's parts. E.g. extensibilty in VB/perl is a performance penalty, whereas extensibility in java/.NET has as much performance potential as anything else.
Slashdot Mirror
I'm sure that exponential feedback systems are to blame here... Nature is all about such systems. We are segregated in our skill sets (both intra-species and extra-species) I believe mostly because of these feedback systems... If you "happen" to do well with a task, your body latches on to it irrationally.. Which focuses your mind and attention towards this task.. You beat at it against all subsequent failure.. Your first impression was that of attachment.. You are destined to become an expert one day (even if only a poor one).
Conversely, if your experiences are negatively received, then you will have a distaste and a self-distracting clumsiness on the topic.. Continuously re-inforcing your ego that this is not for you.
Balance, for example is a prime athletic skill... If you have it, you have a tremendous range of abilities. You can be a risk taker because you 'irrationally' trust that your body can move the way you envision it to.. In fact, you don't even always plan out your path... You trust (from history) that you'll figure it out as you go. And sure enough, most of the time your body will silently surprise you. But a clumsy person will impeed in their ability to take on even the most basic walking, turning, backing-up skills.. Fearing any irregular course of action without a fully thought out plan.. Visibly seeing all the potential pit-falls, and blindly letting them happen (almost seaking them out.. exaggerting sometimes when with an audience).
So when you are in your attached element (beit math, music, art, literature, etc), your mind provides the appropriate positive feedback that glides you effortlessly along - enhancing your skill-set. And the more bredth in a topic you have, the fewer empediments (especially in math).. Without exception, those that I've seen that do well in math classes had a tremendous amount of extra-carricular knowledge on the topic.. Those that did poorly, could be found to be poor at many of the fundamentals of math. Likewise with computer science. (Two topics on which I have reguarly tutored)
We live in an age where ability is valued more than character, by a long shot. I wonder what would be the result of a more balanced perspective?
Italy
These could be used to implement very fast message passing between threads (process some data, store it somewhere, then atomically write the address to the end of a queue) with no need to perform a system call (which meant no saving and loading of the CPU state, just jumping cheaply into a mode that could access a few more registers).
I'm confused, why would you need a system command to pass messages between threads? Isn't that what atomic read-and-write ASM commands are for? That plus thread-shared memory? I have a foggy memory of the alpha instruction set, but other than perhaps a more sophisticated cache-locking, I don't see what they could have that was more innovative for message passing.
I would say that most threaded message passing these days have significantly more overhead. So aside from certain single-function high performance applications, I don't see much advantage to these techniques anymore. You've got apache and mem-mapped shared-memory segments for worker allocation management.. You've got similar environments under postgres (using ID oriented shared-memory segments and semephores).. You've got mysql with multi-threaded shared memory (and likely with atomic read-write mutex's). All of these are using well defined C multi-threading models that - other than setup - don't require OS commands.. Granted a c-library mutex might call a yield system command if the local spin-lock-loop runs too long. But you can't get around that without a change in the core application's algorithm.
Or am I missing something related to VM implementation?
Modern x86 chips do multiple flops per cycle
:)
I love acronyms that are explained incorrectly..
Floating Point Operations Per Second per cycle
If you assume that the reader doesn't know the meaning, then just write it out to begin with.
They don't know good writing -- as the great producers of the past did.
I disagree.. Movies parallel the music industry.. In that industry I am aware of scouts which are looking for a formula. They have investigated very deeply the trends in music that sell and don't sell - they regurgitate that formula in most any new work that gets taken on and promoted.
It's also interesting that the formula is self-fullfilling.. Repetition of a genre produces a tolerance and then a taste for it.. Which facilitates more profit via repetition.
I'm sure a lot of this applies to script selection... Don't make it too complicated, too deep or too emotional, because you scare off a large audience.. Which then produces an audience devoid of depth, which would not be able to accept a deep/complex movie in the future. And even screen plays that are complex can often be edited down.
Also, as you can dramatically see in popular books that have become movies, the focus of the screen-writer can dramatically alter what the reader/watcher experiences (almost always for the worse).
While that's really cool and all.. I wonder if that generalization doesn't reduce the flexibility of clustering methods. I can only assume that somewhere it is configured how the machines interact. UNIX used good ole 'rsh hostname command | output' which seems to fullfill the same requirements. UNIX had many tools which were designed to be character stream oriented (cpio, tar, sed, grep) which faciliated this cross-hosting capability. But today, you have to decide whether you're using ssh and whether you're zipping the stream (which algorithm), encrypting the stream (with what algorithm), using which authentication method, etc. It's very nice to be able to
rsync -e 'ssh -C' path1 host:/path2
I'm just saying, while I agree the everything-is-a-file is cool and all, I've found that flexibile configuration is essential.
So it is ok for the founding fathers to stop their government from abusing its power, but it is not all right for us?
Well, yes and no.. Of course any existing power-base is going to demonize revolution as an evil and misguided minority... The "revolutionaries" are necessarily to be sacrificed. If it wasn't sacrifice, then it wouldn't be worth "revolting" e.g. going to war over.
The trick is that you're not likely to have any sort of organization in any potential revolt, as the establishment is successful specifically because it can maintain it's current laws and order [of power structure]. Nothing wrong with that mind you.. Just that the founding fathers' presented sense of civic duty was not something that can easily be attained from the computer desk (modern version of the arm chair).
This is an excellent post and it reflects my perspective very well. But I would add one thing. The value in bio-technology is going to come, not in problem-solving, or geneticlly engineered algorithms, but in fault-tolerance... Which I believe was stated in the article blurb (sorry, haven't read the article).
Currently, when you want redundancy, you have to build 100% replicas, do 100% redundant computation, then have heart-beat monitors which take down failing nodes and notify a human to handle the failure.
You can engineer probable points of failure and only make those aspects redundant to reduce the cost of the overall system. But the problem with that approach is that every component is potentially faulty to some degree (given enough time).
Let my preface by saying IANA Biologist
My understanding of how the brain works is that every system (neuron, etc) has a deminishing degree of redundancy the furthery away from the currently active node. Every neuron has a decreasing (but existance) participation in every action of every other neuron.. By existing, I mean, once out of every hundred million fires, you might fire on behalf of some other neuron. This (in my understanding) is due to the massive farming out of dentrite-trees which provide voltage to most other neurons and thus provide a certain non-zero probability of a non-related neuron in fireing as part of the action tree.
Presumably the value in having this mass participation is that other neurons are reguarly "included" in the decision making process and thus can take over when the neuron gets tired (e.g. when staying up VERY late and having major centers of the brain slowly shut down, but still pulling an all nighter and thus need some cognitive capability).
To engineer a system with this degree of multi-specializated worker nodes, but with the ability to randomly share code between nodes and to occasionally take over (possibly to facilitate heavy loads, but more importantly to handle fail-over gracefully) is what I think is most valueable in such research.
Unless you are doing simulations or rendering or something I just can't see the minor increase as worth it.
I agree with your post, but this part stuck out. Why is it, that on a slashdot geek site, nobody ever references CPU performance to programming desktop/work-station use. Photoshop, servers and games seem to be the main reasons people justify the highest-performance machines. But ever since I was in high-school (in the 80s), I've always overtaxed my machine... I've never had a machine and said "for what I do, this is sufficient".. And it never mattered what it was I was doing.. Beit running windows (in the 90s) and experiencing the dreaded context-switch pause... Beit Linux and running evolution + spam-filtering + "grep -r" on something - I've always gone "man It sucks working on this machine at work, v.s. the machine I have at home collecting dust". And my work machine has never been a slouch (currently a AMD 2800+ Barton with 1.5Gig of RAM).
Now if a linux programmer uses vi all day and ssh's to a beefy build-machine, then I can understand them not needing a beefier desktop/work-station. But I use to use xemacs and THAT was slow on many machine in the late 90s. Now I use a java editor named idea (commercial counterpart to eclipse) and every ounce of horse-power I can muster I long for. With intelligent real-time code analysis, there is no longer such a thing as idle-time on the work-station. Then add the fact that you can put your application server on your desktop, along with a full project-management suite (evolution, time-tracking tools, dozens of terminal windows, dozens of browser windows...). Waiting 20 seconds for the mouse to regain focus because I'm deploying a new application is just painful. Now do this 5 times in quick succession because you're iteratively debugging something.. Multi-CPU is a god-send for this type of environment.
My point is that I almost never hear people referencing this type of multi-application work-environment as a justification for cheap-but-beefy machines (except for the ubiquitous reference to photoshop, which can kiss my *@@).
That's not the correct way to be doing things, anyway. Try this instead
You missed the part where I compared it to cooperative multi-tasking.. You are wrapping the collection at constructor time, BUT half (and I do mean half) of the time you don't have control over the constructor to an object.. Especially if you are writing middle-ware code, which is most of what Java does - at least good application designs write most of their code in the form of middle-ware.
Take Sort for example... It can't depend on the fact that even though it asks for a generified collection that there is any sort of type-safety involved.. The only thing it can do is pre-validate the data-type of the existing items in the collection that is passed to it. But that's a performance hit, and the ONLY thing that this will do is produce a more meaningful runtime exception.. i.e. instead of an exception in the comparator you get one in the sorter with an explicit "element in collection of type X was really Y" RuntimeException.
Caches, Marshellers / Serializers, IPC services, persistence sercies, etc. They all are middleware applications which throw really really confusing errors sometimes because they aren't passed the expected classes. And when I say confusing, I mean they don't often throw class-cast exceptions, but instead meta-data mismatch exceptions.. But that leads you to believe that you've missed an attribute in the XML configuration instead of the fact that you've adding an object of the wrong type to the middle-layer.
Ideally, generics would be fully enforced by the VM. What we currently have (even with the spettering of Collections.unmodifiable,synchronized,checked etc are weak-enforcement which at best provides spot cleanness of code.. But any static anylizer tool could have detected innappropriate local bugs.. The more critical bugs are inter-moule bugs. And APIs of that sort tend to be littered with innappropriate parameter-checking. If you don't think this is a problem, then what is the number 1 security loop-hole in most older C libraries? gets(). This function (for performance purposes) didn't verify the size of the string so it allowed the over-flowing of the buffer and overwriting of user-space memory. Most other languages handle strings in a less performant, but more robust manner, so this type of bug has mostly dissapeared.
In java, with the advent of dynamic proxies and aspect-oriented-programming, the situation is even worse, because inter-module libraries can proxy objects which don't even match the appropriate prototype/interface. So you actually wouldn't get a class-cast-exception, but instead an arbitrary exception (most likely an NPE) inside the InvocationHandler.
This is mostly a rant, but it's based on my growing frustration with the lack of type-safety in java frameworks... Yes, you're certainly free to not use those frameworks.. But with the increasing movement into container-managed services (tomcat, jboss, or even spring/pico-container), this type-looseness is becoming a growing problem.
Sorry, HTML and less thans... :)
Collection<Foo> myFoos = new ArrayList<Foo>();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();
You can't cheat the java type system.
.NET had a triffle of potential (being a rewrite of Java), except that it's got Big [Corporate] Brother to keep it from reaching it's full potential.
You're kidding right.
Bar b = new Bar();
Foo f = (Foo)(Object)b;
Works just fine for me... Until you get the ClassCast Runtime Exception.
Now you might call this a contrived example.. Except that it's not.
How many thousands of function calls take Serializable or worse "Object" as a parameter? Virtually every IPC related activity does at some point. That includes all of j2ee, which are considered "enterprise" level coding frameworks.
Generics was a step in the right direction with compile-time enforcement of "many" of these opaque "Object" APIs.. But It definitely didn't penetrate some of the more important areas; just collections (which was at least the most [mis]used form of generalized types).
But Generics doesn't have any means of enforcement.
Collection myFoos = new ArrayList();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();
will throw a ClassCast Runtime Exception.
Now it's semi-trivial to write collections to enforce type-safety (just like synchornization).. But this is as effective as cooperative multi-tasking was in the 90's at reducing bugs.
Java has a lot of historical baggage that keeps it from being a refined and bug-resistant language.. And the proliferation of XML-configured reflective programming is really getting out of hand. That being said, I am not aware of any other development platform that is as versatile.
So far as living to a ripe old age just 'cos your great-grandaddy did? Don't forget, they didn't have McDonalds to deal with.
You forgot to mention the probability that you will or will not get the gene(s) that let him live to that ripe old age. You could take after your fahter in every way except age expectancy. Especially if the gene is recessive.
So yeah, gene-screening is much more effective I would guess.
The person you are today is an echo of your ancestors and his decisions.
So does that mean you dishonor the 4 billion ancestors that you've forgotten about? While I'm ignorant of ancestrial worship/honoring, I suspect that it's only the ancestors that were famous that people tend to honor (including directly remembered relatives).
I think they should test the subjects general multi-tasking ability and come up with a statistic that correlates multi-taskability (or inability) to accident+phone rates.
But the same could be said about alcohol-inhibition. I've been in the unfortunate situation of needing to drive a few blocks home after having a couple too many drinks... But during this period my adrenaline is pumping because I've ingrown the danger of doing that exact act. I'm sure the shortness of the action allows the adrenalin to compensate..
But the importance is that there is no way of enforcing mental competence.
I don't know about other people.. But my motivation for Open Source contributions have to do with a deeply rooted need for modularity.. Since a child I've been of the opinion that (with a certain cutoff) you should always take the more difficult road; to spend more time now so you don't have to perform repetative tasks later. In video-gameplay, it means spend more on resources (hoping you can fend off early invasion) such that you have greater available resources in the future.. In programming, it means set up reuseable modules or enhanced the capabilities of a module such that it can be used more generally and for more purposes. In terms of projects, it means break the project up into completely isolated and independent functional units which can be used for alternate unrelated projects. In terms of problem solving, it means encapsulate the ideas in such a way that if I move from company to company, I don't have to re-invent the wheel when I come across similar projects (unfortunately there are legal restrictions as to how far I can take this path).
Thankfully my last couple employers were big advocates of OSS, so I was able to take this problem-solving mentality to the level of open-source modules (in perl and java).
So for me, it's not about the love of the OSS process (though that's there).. It's not about giving back to a community from which I so heavily borrow (that's there too). It's not about volunteerism or community service (which a majority of Americans take part in for tasks in whicih they consider hobbies... cleanup, building structures, food-drives, telethons, religious prosecution). It's about pure self-interest... Adam Smith would be proud. My self interest is the need to carry a problem solution outside the borders of a company that could lay me off at ay moment.
Wasn't the new testament based on the teachings of a Jewish Communist?
While I love the idea of what you said, unfortunately it doesn't hold water.. A good communist would be at odds with the government.. They would want to maintain as much self-governance as possible (Waco Texas, etc). That Jew was quoted as saying render unto Ceaser that which is Ceaser's.
He also wasn't much of an economist, so we shouldn't follow his economic example. If we all gave up our possessions and roamed the forests picking fruit from other people's lands on Saturdays so we could perform full time proselytizing, then we'd have a free-rider problem - nobody would cultivate the fruits (nor have the capital to invest in next years crops), and thus we'd all starve after the first season.
I hadn't read the article, so I missed the fact that it was a man in the middle attack. But that doesn't obviate the need for securing the authentication process to facilitate public trust. Again, I recognize that IRC is limited to what it can support in terms of authentication (similar to telnet).. But I did want to mention that you don't need public key authentication.. HTTP and IMAP (and I assume POP), for example supports client digested passwords (e.g. they are never transmitted). I believe the protocol they support would use the same salt for every login attempt (login + realm + password), so a man-in-the-middle could capture and replay the digested result as easily as for clear-text.. The difference being, you could only use the captured results for the same user + realm + password combination (which presumably is semi-unique across the internet, at least as far as useful attacks go). So now you have digested passwords stored on disk, and digested passwords transmitted across the network (SSL'd or not) and only the login user knows his password.
Again, something like telnet is incredibly limited, but IRC has a specific client, so one would imagine that over the years digested authentication would have been added to the protocol.
My main beef is that I know for a fact that way too many highly sensitive institutions still store passwords in clear text (and encrypting them is as bad as clear-text). I know this is the case because if you go to any web site's "forgot password" section.. If it asks you for your mother's maiden name, the site has two strikes against it.. One is identity-theft (almost as bad as asking for your SSN), and the other is the fact that it seems to care about who you are because it's obviously about to disclose sensitive information to you.. A correct design doesn't HAVE any sensitive information.. A simple "I'll send a message to your cell phone, email, physical-mailing address, transfer money TO your established bank account/credit-card (as does paypal or conversely for USPS)".. Anything where a previously established external form of trust exists. And most importantly the message is a reset of a password, not the original (as that would prove that a clear-text password exists)
I'm not a big browser of IRC's, but do we honestly still use clear text passwords anywhere? I mean unless IRC is such an old service that it can't make use of any of the dozen some odd technologies that have been standardized on in the past 20 years.. come on!!
Who yearns for a time when everything is out of your control and sailing sticks across a pond is fun because you've still to undeveloped mentally to enjoy a good game of Risk?
Risk? I have an 8 year old niece who plays risk.. Come on, Axis and Allies!!
Why wasn't the whole stack written in perl?
.NET (and I'm sure other languages), it's hard to write un-anylizeable code (though with the advent of XML and xdoclet it's getting easier). Note that I didn't say unreadible or unmaintainable.. In Perl you can load a module which forcibly redefines many of your functions.. This is not only feasible, it's common practice.. Now "good practices" says a module should use cooperative symbol injection (meaning the caller asks for symbols to override). In C++ you scatter the definition of your methods throughout many classes using the a::b::c syntax to pull them all together.. Convention reduces the propensity to abuse this, but it's still common practice to use include-file magic to completely alter which methods are compiled in. Java does use reflection and proxies more and more, which are just as bad (and often uses XML to define when/where/how to use such proxies). But this at least only provides "deviations" away from the base code; and more importantly is similar in effect to generalization-specialization... Since OOP often has you over-riding methods, reflection is more like dynamicly coded specialization. So it's no more inelegant than multiple overrides which OOP commonly allows (not aware of all the implementations of OOP)... Of course, you could always choose to say OOP should only ever specialize each method exactly once.
Ok, what about SQL.. That's not even JIT'd. What about about the startup process.. Why isn't that compiled directly into the kernel? Boot-up-times could be insanely fast.. Hell, you could even embed the mysql and apache and slash-code directly as a kernel module (a la tux)... You could have slashOS.
Obviously separation-of-concerns plays a role in these decisions.. But more importantly is the UNIX mentality of tool-boxing. Each language performs a single role (ideally) and each module is built out of the most appropriate tools (including language).
If 90% of the "Thinking" goes into the web request and the database reconciliation, and those aspects of thought are VERY uniform and consistent across all applications, then they BELONG as raw mathmatical code (e.g. c or pascal or take your pick beyond my expertise). Since there is no varyance, there is no benifit in JITing them every time they launch. Incidently if apache or Mysql were done in Java (i.e. hsqldb and tomcat), I doubt there would have been any performance hit, as both apache/mysql are services which have long live-runs, so load and JIT time are neglegable compared to boot-time.
The thing that should be scripted is what is most highly deviating between deployments.. Obviously shell-script being the most crude of the available languages (perhaps surpased by the non-Linux VB-Script), or maybe PHP (which I know many sys-admins who do shell scripts via PHP).
Perl is a fullly featured language (and if you don't believe me, try comparing it to bash and try to escape every possible string, and get back to me). This fact makes perl better than AWK, SED, grep or [ba]sh to do full system programming... Now I would argue that perl doesn't scale well into large projects (code-management wise).. It's harder than C to anylize since almost everythign is symbolic and has side-effects (the fact that whether you last referenced a scalar as a string or integer affects what it does when you concatenate is a big element-of-surprise when performing data-encapsulation). But single-focused applications like bugzilla or even slash-code are perfectly fine to write as perl applications.. You don't have unrelated application-level modules being brought together (meaning while IO::File is a module, it's purpose is to be reused, whereas bugzilla-preference-manager is not meant to be used for anything other than bugzilla... But the author is forced to be aware of the bugzilla-list-bugs module).
With Java and
Someone else's comment about google spread sheets being butt-slow is not an issue of throughput, but latency (both being elements of
Don't forget that, for many years, the USA have been at the forefront of technology and science because the US Governement -- meaning you, Happy American Tax-Payers!
And AT&T was at the fore-front of technology for many years (i.e. Bell Labs). And the robber barons were great philanthropic institutions. The problem is that when you have "excess", it doesn't take a whole lot of brain power to say "maybe some of this could be diverted to research to better suite our future".. It isn't that you're sacrificing anything, but trying to diversify your wealth.
During WWII, the atomic bomb was part of the same excess that we spent on just about all engineering feats during that time.. It was just one of many extremely over-funded projects. Likewise in Germany. The wealth was the pre-allocation of massive funding due to higher taxation and rationed resources. Somewhat similar during the appollo missions (for the cold war).
The reason we're seeing scientific contraction in the US government today is due to the contraction of funds (and thereby the excesses). Republicans are trying to remove the entitlement society that built up over the years.. They're trying to minimize the economic impact of the fully understood environmental issues. Granted, they're minimizing this for their coffers / financial backers. They're doing so by "stalling", by "rhetoric", and in some cases, by outright lieing. This works because most Americans are largely detached from political intricacies - and are instead moved by talking-points. It works because many Americans are deluded into believing that what's best for the 1% is best for them.
The "excess" funding in the military is now being spent on a hot-war. The "need" for NASA has contracted dramatically since the decline of the space-race in the 80's. The NSA is mostly just a commoditized "google" for telephones networks now - most technologies are already in place.
I'd say you are both missing something critical... Context. Firearm means the same in MA as it does in Florida, both to citizens and to the law.. The difference is context. If a lawyer in MA says to the judge or jury "this violates the firearm law XX", there is implicit context of "in this state".. To clearify context, the lawyer might say to the judge or jury "while the victim was in Delaware, he was in violation of the Delaware firearm law YY".
It's exactly the same as a local variable, local object, verses a global variable/object.. The context is often time implicit, and often times requires qualification.
In a programming language, we say "this is a keyword", or "this class extends that class".. But without knowning the particular programming language, those phrases may not have enough meaning.. A keyword in Lisp might have a completely different meaning than one in "c".
You have protocol overhead too of course; 300k 'real' download speed is consistant with a 384k, burstable to 768k, circuit.
I doubt it, though you may know something that I don't. Constellation-chart modems are throughput machines. If you wanted to send a character, then flush the queue, then send another character, then yeah, your sustained is going to absolutely suck, because each chirp you send through is only partially filled.. Especially if you're wrapping each character with a TCP/IP packet. But when you're using throughput testers, you're sending raw contiguous bytes of data with almost no flushing.. Latency is foregone for throughput. Such a thing makes IP and ECC based modulation/demodulation sing (e.g. minimizing the overhead).
Most physical-layer networking architectures that I am aware of scale pretty well in the presense of high contiguous bandwidth users. Latency starts sucking as you add users, but packets and line-ownership times are optimized to send large large chunks at a time (especially considering that a latent sender will have backlogged a large chunk to send). In Ethernet all senders wait until the line is free before initiating a transfer. In token ring, you are given a time-share of those wanting transmission time. T1 and OC1 have various guaranteed bandwith allocations. Full duplex modems don't have collision issues if I recall. I assume DSL is the same (sender and receiver use entirely different frequency ranges, so there is no collision). I don't know what coaxial cable internet uses, but I assume it's similar to cell-phone based technologies (TDMA, CDMA, etc). Collisions (and thereby error detection/correction, resending) arguably play a greater role there.
However, if lowering subscription level in DSL lowers bandwidth, then I highly doubt that the hardware has ANYTHING to do with it.
I would say that VB is to windows what bash/perl/Tk is to UNIX. The things that the two OSes wind up doing the most can be handled by VB or perl respectively.. VB has an excellent form-management editor so it blows away perl/Tk. I didn't realize that VB compiled down to assembly, but I highly doubt that that matters any, as most assembly probably only delegates to VB core libraries. The fact that you can probably optimize a (pseudo code)
.NET might be undesireable because it's interpreted. For the above arguments (that much of VB/perl type languages are nothing more than delegators), that's largerly a moot point. Especially since the interpretedness of java/.NET faclitates a JIT.. You can consolidate all the byte-code of an entire custom-extended core-library (such as Map), and have it become more highly performant than say writing a 'magic' enhancement to the core reg-ex engine of VB or perl, which will never get faster than the sum of it's parts. E.g. extensibilty in VB/perl is a performance penalty, whereas extensibility in java/.NET has as much performance potential as anything else.
for x in 1 to 100
tot *= x
end for
to raw assembly probably does not affect 99% of the code that is generated for a VB app. Perl, on the other hand doesn't have the assembly option.. The closest I ever saw was something that wrote out c-code to render the AST - thereby skipping the parser stage. I was under the impression that VB compilation was merely a tokenizer (similar to python). In perl all variables are advanced objects which can type-cast on the fly (and keep caches of previous type castings in case they flip flop back and forth, say between a string, an int and a double). I recall VB having similar opaqueness (though I also recal that you can designate more stringent data-types). The effect is that the simple 'total = total operator varable' is not going to translate directly into assembly code very nicely.. Especially if the language can support side-effects in variable assignment (perl is notoriuos for this.. They even call it a reference's 'magic' setting).
I've seen people comment that