And i must say i also like categories and delegates, which allow surprisingly well organized code.
Categories are fine as far they go (in alleviating needless COBOL like block rigidity of class interface/implementation which get in the way for larger classes; without that rigidity they wouldn't buy you much). Unfortunately, without category being able to have its own variables (ideally with its own name space), you still end up bunching all the variables you need in a category back into the header of the main class interface, imported by others (making it more difficult to fully isolate autonomous parts of the category functionality).
As to delegates, the fixed names of the delegate callbacks make it difficult to have multiple handlers for different callback services of the same type in the same class, e.g. returns from alerts or action sheets for several popups that class may use.
I have tried multiple times to get into Objective-C and Cocoa. I just can't do it and Objective-C is why.
After about a week upon installing SDK and playing with their samples, I spent couple weeks writing macros and wrappers (which grew over time to 5-6 thousand macros+functions) for much of Obj-C/Cocoa that I needed, so the worst stuff is out of sight in much of my code. I also ported my string library (the Cocoa NSString is about the worst string library you will ever encounter), linked lists, hash tables, small blocks sub-allocator... and avoid NSStrings, NSDictionary, NSArray... for anything other than Cocoa APIs requiring them. While the resulting code still isn't as clean and elegant as one can get with C++ or Java, or even Javascript with good libraries, it was managable enough to complete several complex apps (full remote desktop control, remote file access/manager, remote cams viewer, and some fun ones, like golf range finder and break reader, which worked quite well despite the flimsy iPhone accelerometer).
There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature").
I have debated Apple guys on SDK forum (until some big guy, evangelist, got annoyed with the heresy and put a stop to the discussion), asking them to show what exactly can't be done hundreds of times faster (with properly integrated compiler/linker/loader) than their runtime hash tables are doing, and I couldn't get one example that could stand after closer analysis of the tasks. Basically, the guy who created Obj-C was toying with OOP concepts (even he doesn't use it any more), he didn't get the key point of OOP (tools for building layers of abstraction, via flexible name spaces and overloading), and somehow he impressed Steve Jobs, who knew even less about compilers and programming, in his Next phase, and everyone is now stuck with half baked language and hyper-verbose wasteful Cocoa, which leave good chunk of the compiler/linker/loader job to the programmers and end users' CPUs.
Have fun re-implementing something like KVC/KVO in C++.
Now that you mention it, KVC/KVO is another one of ridiculous and wasteful (on end user's CPU & programmer's time) "features" of the Cocoa API. Passing simple numeric arguments of time critical functions (such as animation control) as ascii string objects (not just ascii strings, but malloced strings, which need to be parsed & converted into binary integer/float then free-ed) is utter idiocy. If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs). It's beyond stupid. Similarly, passing 4 byte IP addresses to their CFNetwork APIs (their wrapper around BSD sockets) as malloced objects is just a mind boggling wastefulness. And all that wastefulness on a mobile device, burning away the batteries.
As with everything Apple, where sparks of genius are smothered by cult-like rigidity and idiocy, they are going to squander again the gigantic edge they had with the iPhone (which is a great device), just as they did it with Apple II after IBM PC took over, then later after pioneering PC GUI with Mac, they lost the market to Windows which was ten years behind, despite the latter being fueled by the famous Microsoft's creativity and excellence. They are now repeating their old pattern with iPhone (and, among others, their religious devotion to the clunky, wasteful Obj-C/Cocoa). In couple years Android and Mobile Windows, or maybe something better, will leave Apple with their usual 5% niche of the market.
After about two years programming Obj-C/Cocoa for iPhone apps, I can't believe that this ancient experiment in OOP by an amateur compiler writer is still around. Even though it is nominally a compiled language, all the calls to methods as well as accesses to class properties are interpreted -- the name of the method & its args (args have names) is looked up in a hash table by runtime interpreter to find the address, then to push args and call it, every time you invoke it or access a property. The Obj-C creator basically didn't know how to code linker-loader address binding and so he just left that part for the runtime to decode on millions of end users CPUs from there on. He also didn't know about name mangling, and left that part of his job for the future programmers to do manually (method names and args are explicitly named, so you end up with arg named calling methods like [obj method:arg1 count:count]). For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing. The syntax is very clunky, inelegant, uneconomical on programmer's time e.g. requiring lot's of jumping back and forth to match/complete nested square brackets, again simplifying compiler writer's job at the expense of busy work for countless programmers from there on.
In addition to performance & narrow technical issues, the worst fundamental flaw of Obj-C is that the creator didn't understand the value of name space partitioning in OOP (the key tool for building layers of abstraction), so much of that's left largely to programmers, which in Cocoa (API, like win32) resulted in mind-numbing hyper-verbosity, with each class and method names dragging huge repetitive prefixes, with each name spelling out explicitly its whole ancestry back to the stone age. While the Xcode editor is doing heoric efforts in trying to guess what you meant and offer auto-completion of the names as you type, that is the lesser half of the problem (you still end up doing lots of cut & paste of the Cocoa names). The main drawback is when trying to read or modify the code later -- even the simplest algorithm looks complex, any pattern specific to the task at hand is drowned in the mind-numbing sea of repetitive Cocoa verbiage.
In short, horrible language & API framework. Only someone who grew up with this and never knew anything better could love it. Of course, like everything Apple, buried under the idiotic Coca+Obj-C layer, there are gems of genius, especially the extremely well thought out functionality and high performance graphics & animation engines.
The genes are more like global variables, while the auto variables and the actual code is in the "junk" DNA. Our scientific priesthoods (in any field) behave exactly like the ancient Egyptian priesthoods who, after figuring out a bit of a pattern behind calendar seasons, star constellations and Nile cycles, declared themselves all-knowing about everything there is, on earth and in heavens, before and after death. Among others, they declared brain as unimportant organ used only for cooling.
The worst offenders nowdays are public health "scientists" who pick out from vast patient databases (using statistical software which is a mysterious magic wand for most of them) some correlations on self-selected subjects, which could mean anything, then hand-pick one possible explanation as the "real" one (coincidentally, it is always the one benefiting financially the most their sponsors, pharmaceutical industry), declare pompously "science has spoken, debate is over" and then use it to drive policies, regulations and medical expenditures. Their "science" invariably ends up in more control over your life, worse health for you and your family (e.g. recent rapid rise of autism, asthma, allergies, obesity, diabetes, dialysis...) and more money going from your pocket to theirs and of their sponsors.
The author's entire argument is based on the dubious leap: since we haven't observed any advanced civilization that they don't exist and that they are not here. How does he know our present science, theory or experiment, is sufficient for such observation? Can bacteria understand what Slashdot is? There could far greater gap than that between our present knowledge and a civilization which is few billion years ahead of us.
Consider, for example that in our present physics the low edge of space-time scale is at 1E-33 meters, the Planckian scale, while our "elementary" particles or any experiments are at the scale 1E-16 m or greater. The region between 10E-16m and 1E-33m is a "desert" as far as anyone knows. Yet this "desert" contains as large span of scales as the range between our elementary particles and any lifeform or any of our technological creations.
For all anyone knows there could be the entire hierarchy of complexity, far greater than our own, built between the Planckian scale objects and our present "elementary" particles. While the number of orders of magnitude is the same between the two regions, recall that the "clock" of that underlying hierarchy would be ~1E16 times faster than the clocks of our elementary particles (since signals there travel much shorter distance) and that the density of components making up complexity at that scale would be a cube of that ratio, i.e. this underlying hierarchy of complexity would be 1E50 times more dense, with clocks running 1E16 times faster, than anything we can build with our "elementary" particles. Within such picture, our elementary particles and anything built upon them, would be a galactic scale engineering projects of such super-civilization (which to us would be for all practical purposes god-like). Yet, within our present scientific framework, we wouldn't have a clue that it exists.
Hence, "they" may well be here, and we may be even "their" little project or an experiment, but we are too primitive to recognize any of it. The author starts with a premise of near omniscience of our present science and thus leaps from 'absence of observation' to 'observation of absence' and from there weaves his story. That premise will seem ridiculously arrogant even to our grand-grandchildren hundred years from now, let alone to a civilization few hundred million years more advanced than ours. We may have no more understanding of "them" than one-bit cells in Conway's game of Life have about us.
Oh my God, freedom of speech definitely applies to a PRIVATE website setting outlines for discussion!
You are much to naive about private property and state. For example, would that private website argument work, if the "owners" were to require, say, that no blacks or Jews are allowed to post here? It's their property, right, they can invite there whoever they wish? Or if the owner of a restaurant wishes to have a smoker's room, or god forbid, smokers only restaurant? He owns it, it's his money, he can open such place, right? Or you wish to develop your "private" land which feds have labeled as "wetlands"?... and so on.
State already behaves as if it owns everything. It may be that none of the particular examples matter to you at present, but eventually, your ox will be gored, too. Then you will realize what Ron Paul was talking about and what the bumper stickers "Don't blame me, I voted for Ron Paul" mean.
That 20% was popular count only (which is the 2nd or 3rd place, with 70% reporting) in a straw poll, which is "beauty" contest. Regarding the Maine delegates, he may have won with 35% delegates (at 70% of precincts reporting so far). Check here for details.
Our company, about 30 people, 7 programmers, has no physical office (it is spread over 3 continents and both US coasts in 5 states), and telecommutes instead using this tool. It is a teleconferencing software which has a very good desktop, app and window real time screen shots, similar to Remote Desktop (e.g. VNC, TS), but with synchronized multistream VOIP and common pointers, so one can look over another programmer's code, real time program output/ui or debug dumps (he just brings up his VS and turns on the app type 'screen camera' on), discuss it or present Power Point to the entire team. Multiple people in a conference can turn on their screen broadcasts, microphones, web cams, although for the most part we use it for 2 or 3 programmers at a time, with just mic and screen cams. One can also yield remote control over their desktop or just a single app to another participant (the whole session can be broadcast to entire group e.g. for a demo). Our tech support and sales use it as well, since it lets them take calls from java clients (any potential or existent customer with a browser visiting our web site), triggered by a click at various places on our web pages.
Tech support uses it sometimes with remote control yielded by a customer (through their Java client) to check the reported problems with our apps and their system config. One can even look, with customer permission, in real time into remote threads (Dr. Watson style hex dumps), all windows (a la SDK Spy++), apps, dll's, memory heaps (layout and hex dumps). These latter low level features are usually done when tech support guy has to conference in a programmer into his tech support session to help out with some trickier problem. In 1990s, I used to travel to customer locations to do this kind of troubleshooting.
Except said radiation doesn't have nearly enough energy to knock your DNA out of whack.
Radiation does not have to break off electrons from the atoms (ionizing radiation) to cause biological damage. Quanta of biochemical processes for large molecules have spectra well into RF. The radiation needs only to disrupt some subtle process to cause systematic imbalance.
For example, it has already been known (from earlier microwave experiments in 1960s) that this kind of RF induced disruption does occur, in particular the permeability of the blood brain barrier increases under the O(GHz) exposure. This particular effect has been replicated recently on the RF from cell phones at typical user intensities, with the results clearly measurable after just couple hours of exposure. The researchers pointed out implications of such damage for accelerated brain aging.
While we are at it we can argue about how a few watts of photons with less energy than infrared can cause cancer while kilowatts from a nice comfy open fire do not.
The penetration depth of EM waves is roughly of the size of wavelength. Hence, the infrared radiation from a fire doesn't even penetrate the human skin (the heat will eventually transmit deeper via molecular vibrations but that is a slower mechanicsm and we have evolved a biological warning system via pain sensation), while the RF radiation from the cell phones (or similarly the microwave ovens), which is several orders of magnitudes longer, penetrates and is absorbed by entire brain. Since the presence of RF emitter near brain is a very recent occurence on evolutionary time scales, we don't have a built in biological warning for the damage it does. The whole generation of current teenagers will be going senile in their thirties.
They should have at least used the recreated ancient wood, not the wood used today which is treated with fire retardants. They did it their way because they sought the outcome they got. The mythbusters, like much of the stuff on TV (news, documentaries, movies...) comes with its particular agenda. The old mythology is taken down (e.g. recent gay Alexendar movie, Man in Tights mythbusting Robin Hood etc) to make room for Hollywood mythology. The armies of memes fighting for your neurons.
How do you remove or migrate an application using your method that requires various registrations with the OS or shell? In the simplist case, registrering the application as the default application for a file type?
We do have couple custom file types, one for screen snapshot sequences and the other for the audio+image+pointer sequences (recorded by our app for automated presentations). They are stored into data & web folders from our app-root (the product, hotComm, has also a web server built in with dynamic dns & a bypass of the ISP blocks of port 80 on residential lines).
If the user wants shell registration (as opposed to just viewing or playing files from within the app to the network clients, which is normally all one wants to do), then later decides to remove us entirely via simple folder deletion, the data files with special extensions are also normally gone (nothing really harmful happens even if they aren't and he clicks on them; they just don't play). Presumably, in that case they don't care about any them any more. We have yet to get a single support call or a complaint on that subject. In any case, we do allow clean uninstal (to at least remove our registry pointer to the app root). Similarly, the main exe can run as a service (usually for unattended server operation), which again is on or off toggle within the app (they can control it also from the Windows Services). Since these config options are in our own config files, they move with the app-root and set themselves up in a new place as soon as they run our exe on a new system.
Again, the plain deletion of the whole app causes vastly simpler problems (if any at all) than trying to instal and configure apps over and over from scratch, getting DLLs mangled up,... the usual Windows system32, dll & registry hell.
The deletion is not the real point of the autonomous app-root scheme (they can always run uninstal). It is the instalation and configuration free mobility between the machines, OS & hard disk changes/rebuilds. The whole system is much more resilent since all you need is another copy of the app-root restored and you're back in business. If you had to rebuild complex apps many times over, with full and detailed config which evolved over longer time, than you will realize how much time and trouble that autonomy and mobility can save. The deletion vs uninstal makes no difference to the user in terms of work, and it is not the point of the scheme (even though it does work trouble free).
The current Windows registry & dll setup is a badly misguided scheme conceived by the Stalinist central planing mindset. That kind of stuff doesn't work anywhere well. It's a torture and time waste for the users, making their system inflexible, fragile (to hardware & software failures), virus, spyware and marketoid bullies friendly. Only a virtual monopoly like Windows could get away (while it lasts) with such nonsense.
Apps like yours are a nightmare in multi-user enviroments.
Not al all. It is much easier and simpler for everyone. For instals where only an authenticated user can use given data & network info, our local config folder has the required user info which the exe compares to the currently logged user. You can have as many users & copies & shared combinations of users/copies in any way you wish.
For our development & debug instances, we just create multiple app root folders, each with its own app versions & configs..., allowed for all users on the machine (whoever runs the exe). To upgrade multiple setups on a network, a simple copy to all.\upd folders of all users is done. On the next exe start, the exe checks the.\upd and updates the binaries & does any data format conversions (which is rare) from the upd folder and clears it up. The main exe also gets notifications of required upgrades (and can download them if configured that way) if it is already running.
Where do you expect it to be installed? In every user's home directory, binary and all? Or is there no mind to multiuser support?
We have a single registry entry (in the current user or all users or specific user, depending on what they selected during setup) which points to our app root folder. The rest is completely autonomous from the registry. The sole piece of info in the registry is the app root folder, and even that one is not vital at all. If our app starts and it sees no its own registry entry (or finds an entry pointing to another app root than what the exe sees), it simply adds one for its own app root (the setup type is in our config folder of its local app root, so it doesn't need to ask user anything).
The upgrades find root folders, either from registry or via user selection or via search, for all installed copies and user can then check on all the copies to be upgraded. (Few times we had changed config or data file formats, but the new version setup automatically knows how to convert the older revs.)
It is highly convenient, especially for the users. For us developing and playing with multiple copies all the time, it is quite labor saving as well. E.g. having to debug some customers odd setup & data, one just unzips the customer's app root anywhere and runs the exe from his bin folder -- all his setup & data is self-contained and no damage is done to the other multiple setups we have on the machine. If I need to recompile dll's and try some fix, I just copy it into the bin folder (usually all automatic via make) for the instance being tested. Once fixed and done, I just delete the customer's app root, and it is gone (the single registry entry pointing to test app root is left for future similar tests, so we normally don't bother deleting; our setup can remove those entries without actual app root). If I need to test some problem on particular windows version or particular hardware, I just copy it there and run it -- all the config & data (which could have been tuned for a long time) is ready to go.
Since the win32 registry API goes to the central place, we have our own tree based data base to serve similar purpose, except all its data goes into our local app root copy of our little registry. If only all the apps would do the same, keep their own stuff to themselves, all from its own app root, the windows setups would have been much less fragile and would have saved me enormous amounts of time over the years (just thinking how many times had I installed Visual Studios, Jbuilders, SoftIce, all kinds of tools and servers, Textapds, tex, ghostscript/ghostview, browsers, MS Office, Chessbase programs and other games,... and had to instal & configure them all from scratch on various windows & different machines, on new boot hard disks to replace older/slower/smaller ones; right now I have six machines around my desk, all needed the whole gear, it takes days to get one full setup right, and only one machine has the setup older than a year).
Had all programs been fully autonomous as ours is, I would just had to copy the whole app base (with all the app roots) to another place (which may take an hour or more, albeit unattended) and it would be done, all apps and tools ready to go, configured exactly as they were originally. All the manual work required would be Ctrl-C on the source and Ctrl-V on the destination (and come back in an hour or two when the copy is done).
You should NEVER write configuration files, or data, or ANYTHING runtime related in the same folder as the program.
The data and config folders are sub-folders from our app root folder. The binaries are another subfolder off the app root. They all have a common base folder (our app root) and access the rest relative to this root. To uninstal user simply deletes the app root folder and no trace is left. To move to another machine they just copy our root folder there and it is ready, fully configured. They can even mix and match and copy e.g. users lists and data base (which are off data root) while keeping the local gui config unchanged (which is the local user GUI & network config folder). We basically don't touch registry or windows system folders (although some win32 APIs read the registry settings on their own, which we don't care about). It is vastly simpler and cleaner scheme, for us and for customers (users and admins). We also don't worry about licenses since we check that via the network (where it matters; the client components are largely unrestricted, some are just in java form). They can copy it all they wish.
Mozilla, for example, would have been much better with such scheme -- you just expand binaries to its bin folder, off its app root, and you are done. The way it is now, if your windows needs a clean rebuild, or you need a second copy (with the same data & config on another machine) you need to instal, configure browser, email, html editor,... to any new place, track down and move data, bookmarks... (all hiding somewhere in those mile long windows folder names) lots of wasted time and effort. The whole centralized scheme is extremely labor intensive and fragile. Some day our grandkids will laugh at our ridicuolus, wasteful and irrational Windows ways.
Anyone who suggests 'abandoning the use of the registry' has obviously never written Windows software. What do you suggest we replace it with, INI files?...
I have developed large windows apps and I don't touch registry or any windows folders. Our our app configuration data sits in our own file, in the folder based on the location of executable (we don't use absolute paths for our data & other folers). If user loses OS and has to instal new one from scratch, our software runs exactly as before. If user needs to put our programs to a laptop or another machine, they just copy from our base folder down and it all works in the new place, no reinstal or configure anything. In contrast, most other apps require locating old CDs to be reinstalled, finding unlock codes on some stickers or packaging long gone, registration keys and confirmation emails, full GUI configuration (which may have taken months or years to tune up)... a nightmare.
If app needs a tree-like database to store its configuration, one could have had all the registry API's, except that it stores all the data in a local file within the app folder. If user copies app folder & subfolders, it should all just work. If app needs to look some global configuration (set via windows), it should be via read-only Windows own config database. Similarly, nothing should be allowed to write into windows or system32 folders (such as dll's or other app specific files), unless explicitly allowed by admin user.
In other words, the apps, their data & dll's should be self-contained, isolated from the rest, prohibited from touching or modifying other app folders, data & configurations (unless explicitly allowed by admin). If you don't like some app you just installed, you simply delete its folder and it is gone without trace.
The only item which does need to sit in a common registry is the list of app root folders, to help for example with installing a new version of the app (which would require a proper signature to access the old version data). The applications would not normally care about this common list for routine operation. If the app starts and it has no entry in the app master list (e.g. when system was rebuilt or when you copy app to another machine), the startup could append the entry for the app, so a new version could find it.
Apps which need access to config or data of other apps would need approval by admin user to read, and especially to write into other app folders.
The present Windows scheme is terrible for users and developers, both with registry, DLLs and windows & system32 folder cesspool. It is a completely wrong-headed, oppressive scheme, with no concern for user time and convenience, as if devised by some stalinist era buraucrats.
No doubt random Internet crank is right and Harvard Nobel Laureate (and everyone in that field for decades after) is wrong.
You are welcome to argue substance of the critique (the gist of which is in post-1 and post-2. The questions discussed there happen to be the topic of my masters thesis (in theoretical physics at Brown University). In the years since leaving academia to work in industry, I had followed the developments and studied the literature in this field. Basically the critique is not that Glauber is formally wrong or that Quantum Optics as a branch of applied physics is useless.
The critique is about a small sub-current among the Quantum Opticians misrepresenting their experimental results to the physicists as demonstrating some fundamental non-local effects which apparently seem to manifest, of all the various fields of physics, only in Quantum Optics. In a recent thread in PhysicsForum, Photon "Wave Collapse" Experiment (Yeah sure; AJP Sep 2004, Thorn...), I have debunked a recent QO claim (of "magic" effects observable only in QO), showing exactly how it cheats (it was a pretty blatant fraud in this case).
Generally, though, such claims do not cheat in any blatant way, but merely use the Glauber's QO terminology which has its own definitions for "counts" (which don't count) and "correlations" (which correlate these "counts"), unfamiliar to the physicists who assume that the (photo) "counts" talked about by Quantum Opticians are the actual counts shown by detectors. You can find specific details on how this "QO sleight of hand" works in a related sci.physics.research post discussing the famous 1988 Ou & Mandel experiment (which was the precursor of all modern PDC based B.I. violations experiments) allegedly showing violations of Bell Inequalities. No violations were shown either in the experiment or predicted by the QO/QED, yet the general impression physicists have about these QO experiments is that, ignoring some minor technological imperfections, the theory QO/QED predicts the violations and the experiments show them. The only valid part of such impressions among physicists, though, is that the theory (QO/QED) and the experiment indeed do agree (they agree that there are no B.I. violations).
Interesting timing. Few days earlier, in a debate with some Quantum Opticians, I posted in sci.physics.research several messages criticizing Roy Glauber and his theory of coherence. The last post was at: sci.physics.research thread on Roy Glauber's coherence theory.
So, the only difference between this new flash and ordinary flash is that this one can do LESS ?
Similarly, the only difference between a rock and a Michaelangelo statue is that the statue has less rock. Or a difference between a woman at 18 and the same woman at 40 may be that at 18 her tummy had less fat. Or between you and an equivalent quantity of the same types of atoms that make your body is that your own atoms can be reshaped and rearranged much less while being you than the separate pile of atoms while remaining a pile of atoms. Less, icluding less free is often valuable and good.
This isn't really happening anymore. Yes, smart people still trump over stupid people in most aspects of life, but stupid people still reproduce. Civilization has removed the engine through which drives the evolution of the species.
The rapid brain evolution discovered in the research refers to the two stages, one 37,000 years ago, the other 5800 years ago. The "stupid people" had much greater survival an reproductive disadvantages back then (at least in certain regions of the world where they identified these stages).
While in the present civilized world the "stupid people" are more prolific multipliers, there is still a selection process which prefers the pairing of the stupid with the stupid and the smart with the smart. If continued long enough (perhaps for few dozen of millenia), this process will result in speciation. The existent class divisons and divisions of labor (to physical and intellectual) will then become hardwired into the genes (although these divisons are presently encoded into the genes, due to the viability of interbreeding, they are more like software divisions).
'Talmudic logic' (also known as "Pharisaic logic") is a generic term for the kind of highly stretched, contrived reasoning characteristic of talmudic debating or christian appologia (an example and a few more).
You are being suckered by the ever more imaginative PR gimmicks from the outsourcing lobby. Since they can't use any more the shortage of programmers to open some more the H1B and outsourcing gates, now some slickster has come up with a 'neat idea' to peddle "lack of smartest programmers" based on few hundred working for Google and Yahoo, and then got some Business Week hack to parrot it.
The top 500 (or top 1000 or top 10,000) will always be working for someone and by the talmudic logic of Mr. Ben Elgin, Mr. Robert Hof (in Silicon) Valley and Mr. Jay Greene (in Seattle), that "means" we have shortage and therefore, we must lay off another two hundred thousands of Americans replacing them with Indians. How 'bout shortage of newspaper hacks, based on the same "logic" and "data".
Slashdot Mirror
And i must say i also like categories and delegates, which allow surprisingly well organized code.
Categories are fine as far they go (in alleviating needless COBOL like block rigidity of class interface/implementation which get in the way for larger classes; without that rigidity they wouldn't buy you much). Unfortunately, without category being able to have its own variables (ideally with its own name space), you still end up bunching all the variables you need in a category back into the header of the main class interface, imported by others (making it more difficult to fully isolate autonomous parts of the category functionality).
As to delegates, the fixed names of the delegate callbacks make it difficult to have multiple handlers for different callback services of the same type in the same class, e.g. returns from alerts or action sheets for several popups that class may use.
I have tried multiple times to get into Objective-C and Cocoa. I just can't do it and Objective-C is why.
After about a week upon installing SDK and playing with their samples, I spent couple weeks writing macros and wrappers (which grew over time to 5-6 thousand macros+functions) for much of Obj-C/Cocoa that I needed, so the worst stuff is out of sight in much of my code. I also ported my string library (the Cocoa NSString is about the worst string library you will ever encounter), linked lists, hash tables, small blocks sub-allocator... and avoid NSStrings, NSDictionary, NSArray... for anything other than Cocoa APIs requiring them. While the resulting code still isn't as clean and elegant as one can get with C++ or Java, or even Javascript with good libraries, it was managable enough to complete several complex apps (full remote desktop control, remote file access/manager, remote cams viewer, and some fun ones, like golf range finder and break reader, which worked quite well despite the flimsy iPhone accelerometer).
There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature").
I have debated Apple guys on SDK forum (until some big guy, evangelist, got annoyed with the heresy and put a stop to the discussion), asking them to show what exactly can't be done hundreds of times faster (with properly integrated compiler/linker/loader) than their runtime hash tables are doing, and I couldn't get one example that could stand after closer analysis of the tasks. Basically, the guy who created Obj-C was toying with OOP concepts (even he doesn't use it any more), he didn't get the key point of OOP (tools for building layers of abstraction, via flexible name spaces and overloading), and somehow he impressed Steve Jobs, who knew even less about compilers and programming, in his Next phase, and everyone is now stuck with half baked language and hyper-verbose wasteful Cocoa, which leave good chunk of the compiler/linker/loader job to the programmers and end users' CPUs.
Have fun re-implementing something like KVC/KVO in C++.
Now that you mention it, KVC/KVO is another one of ridiculous and wasteful (on end user's CPU & programmer's time) "features" of the Cocoa API. Passing simple numeric arguments of time critical functions (such as animation control) as ascii string objects (not just ascii strings, but malloced strings, which need to be parsed & converted into binary integer/float then free-ed) is utter idiocy. If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs). It's beyond stupid. Similarly, passing 4 byte IP addresses to their CFNetwork APIs (their wrapper around BSD sockets) as malloced objects is just a mind boggling wastefulness. And all that wastefulness on a mobile device, burning away the batteries.
As with everything Apple, where sparks of genius are smothered by cult-like rigidity and idiocy, they are going to squander again the gigantic edge they had with the iPhone (which is a great device), just as they did it with Apple II after IBM PC took over, then later after pioneering PC GUI with Mac, they lost the market to Windows which was ten years behind, despite the latter being fueled by the famous Microsoft's creativity and excellence. They are now repeating their old pattern with iPhone (and, among others, their religious devotion to the clunky, wasteful Obj-C/Cocoa). In couple years Android and Mobile Windows, or maybe something better, will leave Apple with their usual 5% niche of the market.
After about two years programming Obj-C/Cocoa for iPhone apps, I can't believe that this ancient experiment in OOP by an amateur compiler writer is still around. Even though it is nominally a compiled language, all the calls to methods as well as accesses to class properties are interpreted -- the name of the method & its args (args have names) is looked up in a hash table by runtime interpreter to find the address, then to push args and call it, every time you invoke it or access a property. The Obj-C creator basically didn't know how to code linker-loader address binding and so he just left that part for the runtime to decode on millions of end users CPUs from there on. He also didn't know about name mangling, and left that part of his job for the future programmers to do manually (method names and args are explicitly named, so you end up with arg named calling methods like [obj method:arg1 count:count]). For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing. The syntax is very clunky, inelegant, uneconomical on programmer's time e.g. requiring lot's of jumping back and forth to match/complete nested square brackets, again simplifying compiler writer's job at the expense of busy work for countless programmers from there on.
In addition to performance & narrow technical issues, the worst fundamental flaw of Obj-C is that the creator didn't understand the value of name space partitioning in OOP (the key tool for building layers of abstraction), so much of that's left largely to programmers, which in Cocoa (API, like win32) resulted in mind-numbing hyper-verbosity, with each class and method names dragging huge repetitive prefixes, with each name spelling out explicitly its whole ancestry back to the stone age. While the Xcode editor is doing heoric efforts in trying to guess what you meant and offer auto-completion of the names as you type, that is the lesser half of the problem (you still end up doing lots of cut & paste of the Cocoa names). The main drawback is when trying to read or modify the code later -- even the simplest algorithm looks complex, any pattern specific to the task at hand is drowned in the mind-numbing sea of repetitive Cocoa verbiage.
In short, horrible language & API framework. Only someone who grew up with this and never knew anything better could love it. Of course, like everything Apple, buried under the idiotic Coca+Obj-C layer, there are gems of genius, especially the extremely well thought out functionality and high performance graphics & animation engines.
The worst offenders nowdays are public health "scientists" who pick out from vast patient databases (using statistical software which is a mysterious magic wand for most of them) some correlations on self-selected subjects, which could mean anything, then hand-pick one possible explanation as the "real" one (coincidentally, it is always the one benefiting financially the most their sponsors, pharmaceutical industry), declare pompously "science has spoken, debate is over" and then use it to drive policies, regulations and medical expenditures. Their "science" invariably ends up in more control over your life, worse health for you and your family (e.g. recent rapid rise of autism, asthma, allergies, obesity, diabetes, dialysis...) and more money going from your pocket to theirs and of their sponsors.
Consider, for example that in our present physics the low edge of space-time scale is at 1E-33 meters, the Planckian scale, while our "elementary" particles or any experiments are at the scale 1E-16 m or greater. The region between 10E-16m and 1E-33m is a "desert" as far as anyone knows. Yet this "desert" contains as large span of scales as the range between our elementary particles and any lifeform or any of our technological creations.
For all anyone knows there could be the entire hierarchy of complexity, far greater than our own, built between the Planckian scale objects and our present "elementary" particles. While the number of orders of magnitude is the same between the two regions, recall that the "clock" of that underlying hierarchy would be ~1E16 times faster than the clocks of our elementary particles (since signals there travel much shorter distance) and that the density of components making up complexity at that scale would be a cube of that ratio, i.e. this underlying hierarchy of complexity would be 1E50 times more dense, with clocks running 1E16 times faster, than anything we can build with our "elementary" particles. Within such picture, our elementary particles and anything built upon them, would be a galactic scale engineering projects of such super-civilization (which to us would be for all practical purposes god-like). Yet, within our present scientific framework, we wouldn't have a clue that it exists.
Hence, "they" may well be here, and we may be even "their" little project or an experiment, but we are too primitive to recognize any of it. The author starts with a premise of near omniscience of our present science and thus leaps from 'absence of observation' to 'observation of absence' and from there weaves his story. That premise will seem ridiculously arrogant even to our grand-grandchildren hundred years from now, let alone to a civilization few hundred million years more advanced than ours. We may have no more understanding of "them" than one-bit cells in Conway's game of Life have about us.
You are much to naive about private property and state. For example, would that private website argument work, if the "owners" were to require, say, that no blacks or Jews are allowed to post here? It's their property, right, they can invite there whoever they wish? Or if the owner of a restaurant wishes to have a smoker's room, or god forbid, smokers only restaurant? He owns it, it's his money, he can open such place, right? Or you wish to develop your "private" land which feds have labeled as "wetlands"?
State already behaves as if it owns everything. It may be that none of the particular examples matter to you at present, but eventually, your ox will be gored, too. Then you will realize what Ron Paul was talking about and what the bumper stickers "Don't blame me, I voted for Ron Paul" mean.
That 20% was popular count only (which is the 2nd or 3rd place, with 70% reporting) in a straw poll, which is "beauty" contest. Regarding the Maine delegates, he may have won with 35% delegates (at 70% of precincts reporting so far). Check here for details.
Tech support uses it sometimes with remote control yielded by a customer (through their Java client) to check the reported problems with our apps and their system config. One can even look, with customer permission, in real time into remote threads (Dr. Watson style hex dumps), all windows (a la SDK Spy++), apps, dll's, memory heaps (layout and hex dumps). These latter low level features are usually done when tech support guy has to conference in a programmer into his tech support session to help out with some trickier problem. In 1990s, I used to travel to customer locations to do this kind of troubleshooting.
Except said radiation doesn't have nearly enough energy to knock your DNA out of whack.
Radiation does not have to break off electrons from the atoms (ionizing radiation) to cause biological damage. Quanta of biochemical processes for large molecules have spectra well into RF. The radiation needs only to disrupt some subtle process to cause systematic imbalance.
For example, it has already been known (from earlier microwave experiments in 1960s) that this kind of RF induced disruption does occur, in particular the permeability of the blood brain barrier increases under the O(GHz) exposure. This particular effect has been replicated recently on the RF from cell phones at typical user intensities, with the results clearly measurable after just couple hours of exposure. The researchers pointed out implications of such damage for accelerated brain aging.
While we are at it we can argue about how a few watts of photons with less energy than infrared can cause cancer while kilowatts from a nice comfy open fire do not.
The penetration depth of EM waves is roughly of the size of wavelength. Hence, the infrared radiation from a fire doesn't even penetrate the human skin (the heat will eventually transmit deeper via molecular vibrations but that is a slower mechanicsm and we have evolved a biological warning system via pain sensation), while the RF radiation from the cell phones (or similarly the microwave ovens), which is several orders of magnitudes longer, penetrates and is absorbed by entire brain. Since the presence of RF emitter near brain is a very recent occurence on evolutionary time scales, we don't have a built in biological warning for the damage it does. The whole generation of current teenagers will be going senile in their thirties.
There is also a delayed rounding (see page 7-8) used in combinatorial compression (enumerative coding).
As I know, cloth burns much better then wood
They should have at least used the recreated ancient wood, not the wood used today which is treated with fire retardants. They did it their way because they sought the outcome they got. The mythbusters, like much of the stuff on TV (news, documentaries, movies...) comes with its particular agenda. The old mythology is taken down (e.g. recent gay Alexendar movie, Man in Tights mythbusting Robin Hood etc) to make room for Hollywood mythology. The armies of memes fighting for your neurons.
How do you remove or migrate an application using your method that requires various registrations with the OS or shell? In the simplist case, registrering the application as the default application for a file type?
We do have couple custom file types, one for screen snapshot sequences and the other for the audio+image+pointer sequences (recorded by our app for automated presentations). They are stored into data & web folders from our app-root (the product, hotComm, has also a web server built in with dynamic dns & a bypass of the ISP blocks of port 80 on residential lines).
If the user wants shell registration (as opposed to just viewing or playing files from within the app to the network clients, which is normally all one wants to do), then later decides to remove us entirely via simple folder deletion, the data files with special extensions are also normally gone (nothing really harmful happens even if they aren't and he clicks on them; they just don't play). Presumably, in that case they don't care about any them any more. We have yet to get a single support call or a complaint on that subject. In any case, we do allow clean uninstal (to at least remove our registry pointer to the app root). Similarly, the main exe can run as a service (usually for unattended server operation), which again is on or off toggle within the app (they can control it also from the Windows Services). Since these config options are in our own config files, they move with the app-root and set themselves up in a new place as soon as they run our exe on a new system.
Again, the plain deletion of the whole app causes vastly simpler problems (if any at all) than trying to instal and configure apps over and over from scratch, getting DLLs mangled up,... the usual Windows system32, dll & registry hell.
The deletion is not the real point of the autonomous app-root scheme (they can always run uninstal). It is the instalation and configuration free mobility between the machines, OS & hard disk changes/rebuilds. The whole system is much more resilent since all you need is another copy of the app-root restored and you're back in business. If you had to rebuild complex apps many times over, with full and detailed config which evolved over longer time, than you will realize how much time and trouble that autonomy and mobility can save. The deletion vs uninstal makes no difference to the user in terms of work, and it is not the point of the scheme (even though it does work trouble free).
The current Windows registry & dll setup is a badly misguided scheme conceived by the Stalinist central planing mindset. That kind of stuff doesn't work anywhere well. It's a torture and time waste for the users, making their system inflexible, fragile (to hardware & software failures), virus, spyware and marketoid bullies friendly. Only a virtual monopoly like Windows could get away (while it lasts) with such nonsense.
Apps like yours are a nightmare in multi-user enviroments.
.\upd folders of all users is done. On the next exe start, the exe checks the .\upd and updates the binaries & does any data format conversions (which is rare) from the upd folder and clears it up. The main exe also gets notifications of required upgrades (and can download them if configured that way) if it is already running.
Not al all. It is much easier and simpler for everyone. For instals where only an authenticated user can use given data & network info, our local config folder has the required user info which the exe compares to the currently logged user. You can have as many users & copies & shared combinations of users/copies in any way you wish.
For our development & debug instances, we just create multiple app root folders, each with its own app versions & configs..., allowed for all users on the machine (whoever runs the exe). To upgrade multiple setups on a network, a simple copy to all
Where do you expect it to be installed? In every user's home directory, binary and all? Or is there no mind to multiuser support?
We have a single registry entry (in the current user or all users or specific user, depending on what they selected during setup) which points to our app root folder. The rest is completely autonomous from the registry. The sole piece of info in the registry is the app root folder, and even that one is not vital at all. If our app starts and it sees no its own registry entry (or finds an entry pointing to another app root than what the exe sees), it simply adds one for its own app root (the setup type is in our config folder of its local app root, so it doesn't need to ask user anything).
The upgrades find root folders, either from registry or via user selection or via search, for all installed copies and user can then check on all the copies to be upgraded. (Few times we had changed config or data file formats, but the new version setup automatically knows how to convert the older revs.)
It is highly convenient, especially for the users. For us developing and playing with multiple copies all the time, it is quite labor saving as well. E.g. having to debug some customers odd setup & data, one just unzips the customer's app root anywhere and runs the exe from his bin folder -- all his setup & data is self-contained and no damage is done to the other multiple setups we have on the machine. If I need to recompile dll's and try some fix, I just copy it into the bin folder (usually all automatic via make) for the instance being tested. Once fixed and done, I just delete the customer's app root, and it is gone (the single registry entry pointing to test app root is left for future similar tests, so we normally don't bother deleting; our setup can remove those entries without actual app root). If I need to test some problem on particular windows version or particular hardware, I just copy it there and run it -- all the config & data (which could have been tuned for a long time) is ready to go.
Since the win32 registry API goes to the central place, we have our own tree based data base to serve similar purpose, except all its data goes into our local app root copy of our little registry. If only all the apps would do the same, keep their own stuff to themselves, all from its own app root, the windows setups would have been much less fragile and would have saved me enormous amounts of time over the years (just thinking how many times had I installed Visual Studios, Jbuilders, SoftIce, all kinds of tools and servers, Textapds, tex, ghostscript/ghostview, browsers, MS Office, Chessbase programs and other games,... and had to instal & configure them all from scratch on various windows & different machines, on new boot hard disks to replace older/slower/smaller ones; right now I have six machines around my desk, all needed the whole gear, it takes days to get one full setup right, and only one machine has the setup older than a year).
Had all programs been fully autonomous as ours is, I would just had to copy the whole app base (with all the app roots) to another place (which may take an hour or more, albeit unattended) and it would be done, all apps and tools ready to go, configured exactly as they were originally. All the manual work required would be Ctrl-C on the source and Ctrl-V on the destination (and come back in an hour or two when the copy is done).
You should NEVER write configuration files, or data, or ANYTHING runtime related in the same folder as the program.
The data and config folders are sub-folders from our app root folder. The binaries are another subfolder off the app root. They all have a common base folder (our app root) and access the rest relative to this root. To uninstal user simply deletes the app root folder and no trace is left. To move to another machine they just copy our root folder there and it is ready, fully configured. They can even mix and match and copy e.g. users lists and data base (which are off data root) while keeping the local gui config unchanged (which is the local user GUI & network config folder). We basically don't touch registry or windows system folders (although some win32 APIs read the registry settings on their own, which we don't care about). It is vastly simpler and cleaner scheme, for us and for customers (users and admins). We also don't worry about licenses since we check that via the network (where it matters; the client components are largely unrestricted, some are just in java form). They can copy it all they wish.
Mozilla, for example, would have been much better with such scheme -- you just expand binaries to its bin folder, off its app root, and you are done. The way it is now, if your windows needs a clean rebuild, or you need a second copy (with the same data & config on another machine) you need to instal, configure browser, email, html editor,... to any new place, track down and move data, bookmarks... (all hiding somewhere in those mile long windows folder names) lots of wasted time and effort. The whole centralized scheme is extremely labor intensive and fragile. Some day our grandkids will laugh at our ridicuolus, wasteful and irrational Windows ways.
Anyone who suggests 'abandoning the use of the registry' has obviously never written Windows software. What do you suggest we replace it with, INI files?...
I have developed large windows apps and I don't touch registry or any windows folders. Our our app configuration data sits in our own file, in the folder based on the location of executable (we don't use absolute paths for our data & other folers). If user loses OS and has to instal new one from scratch, our software runs exactly as before. If user needs to put our programs to a laptop or another machine, they just copy from our base folder down and it all works in the new place, no reinstal or configure anything. In contrast, most other apps require locating old CDs to be reinstalled, finding unlock codes on some stickers or packaging long gone, registration keys and confirmation emails, full GUI configuration (which may have taken months or years to tune up)... a nightmare.
If app needs a tree-like database to store its configuration, one could have had all the registry API's, except that it stores all the data in a local file within the app folder. If user copies app folder & subfolders, it should all just work. If app needs to look some global configuration (set via windows), it should be via read-only Windows own config database. Similarly, nothing should be allowed to write into windows or system32 folders (such as dll's or other app specific files), unless explicitly allowed by admin user.
In other words, the apps, their data & dll's should be self-contained, isolated from the rest, prohibited from touching or modifying other app folders, data & configurations (unless explicitly allowed by admin). If you don't like some app you just installed, you simply delete its folder and it is gone without trace.
The only item which does need to sit in a common registry is the list of app root folders, to help for example with installing a new version of the app (which would require a proper signature to access the old version data). The applications would not normally care about this common list for routine operation. If the app starts and it has no entry in the app master list (e.g. when system was rebuilt or when you copy app to another machine), the startup could append the entry for the app, so a new version could find it.
Apps which need access to config or data of other apps would need approval by admin user to read, and especially to write into other app folders.
The present Windows scheme is terrible for users and developers, both with registry, DLLs and windows & system32 folder cesspool. It is a completely wrong-headed, oppressive scheme, with no concern for user time and convenience, as if devised by some stalinist era buraucrats.
No doubt random Internet crank is right and Harvard Nobel Laureate (and everyone in that field for decades after) is wrong.
You are welcome to argue substance of the critique (the gist of which is in post-1 and post-2. The questions discussed there happen to be the topic of my masters thesis (in theoretical physics at Brown University). In the years since leaving academia to work in industry, I had followed the developments and studied the literature in this field. Basically the critique is not that Glauber is formally wrong or that Quantum Optics as a branch of applied physics is useless.
The critique is about a small sub-current among the Quantum Opticians misrepresenting their experimental results to the physicists as demonstrating some fundamental non-local effects which apparently seem to manifest, of all the various fields of physics, only in Quantum Optics. In a recent thread in PhysicsForum, Photon "Wave Collapse" Experiment (Yeah sure; AJP Sep 2004, Thorn...), I have debunked a recent QO claim (of "magic" effects observable only in QO), showing exactly how it cheats (it was a pretty blatant fraud in this case).
Generally, though, such claims do not cheat in any blatant way, but merely use the Glauber's QO terminology which has its own definitions for "counts" (which don't count) and "correlations" (which correlate these "counts"), unfamiliar to the physicists who assume that the (photo) "counts" talked about by Quantum Opticians are the actual counts shown by detectors. You can find specific details on how this "QO sleight of hand" works in a related sci.physics.research post discussing the famous 1988 Ou & Mandel experiment (which was the precursor of all modern PDC based B.I. violations experiments) allegedly showing violations of Bell Inequalities. No violations were shown either in the experiment or predicted by the QO/QED, yet the general impression physicists have about these QO experiments is that, ignoring some minor technological imperfections, the theory QO/QED predicts the violations and the experiments show them. The only valid part of such impressions among physicists, though, is that the theory (QO/QED) and the experiment indeed do agree (they agree that there are no B.I. violations).
Interesting timing. Few days earlier, in a debate with some Quantum Opticians, I posted in sci.physics.research several messages criticizing Roy Glauber and his theory of coherence. The last post was at: sci.physics.research thread on Roy Glauber's coherence theory.
So, the only difference between this new flash and ordinary flash is that this one can do LESS ?
Similarly, the only difference between a rock and a Michaelangelo statue is that the statue has less rock. Or a difference between a woman at 18 and the same woman at 40 may be that at 18 her tummy had less fat. Or between you and an equivalent quantity of the same types of atoms that make your body is that your own atoms can be reshaped and rearranged much less while being you than the separate pile of atoms while remaining a pile of atoms. Less, icluding less free is often valuable and good.
This isn't really happening anymore. Yes, smart people still trump over stupid people in most aspects of life, but stupid people still reproduce. Civilization has removed the engine through which drives the evolution of the species.
The rapid brain evolution discovered in the research refers to the two stages, one 37,000 years ago, the other 5800 years ago. The "stupid people" had much greater survival an reproductive disadvantages back then (at least in certain regions of the world where they identified these stages).
While in the present civilized world the "stupid people" are more prolific multipliers, there is still a selection process which prefers the pairing of the stupid with the stupid and the smart with the smart. If continued long enough (perhaps for few dozen of millenia), this process will result in speciation. The existent class divisons and divisions of labor (to physical and intellectual) will then become hardwired into the genes (although these divisons are presently encoded into the genes, due to the viability of interbreeding, they are more like software divisions).
Talmudic? What does religion have to do with it?
'Talmudic logic' (also known as "Pharisaic logic" ) is a generic term for the kind of highly stretched, contrived reasoning characteristic of talmudic debating or christian appologia (an example and a few more).
You are being suckered by the ever more imaginative PR gimmicks from the outsourcing lobby. Since they can't use any more the shortage of programmers to open some more the H1B and outsourcing gates, now some slickster has come up with a 'neat idea' to peddle "lack of smartest programmers" based on few hundred working for Google and Yahoo, and then got some Business Week hack to parrot it.
The top 500 (or top 1000 or top 10,000) will always be working for someone and by the talmudic logic of Mr. Ben Elgin, Mr. Robert Hof (in Silicon) Valley and Mr. Jay Greene (in Seattle), that "means" we have shortage and therefore, we must lay off another two hundred thousands of Americans replacing them with Indians. How 'bout shortage of newspaper hacks, based on the same "logic" and "data".