A lot of truth in what you say. But then if you did do this XML itself just a concrete realization of a database. So why choose something as inefficient as XML? The only time XML has something resembling efficiency that I can see is when the best method for the job is specifically markup in nature. (i.e. text formatting) rather than data serialization.
So I think that answers the question of why XML isn't pure binary. People want the visual attraction of seeing how the DB structures is formed by inspecting the file by hand.
Unless you assume the depth of recursion is not proportional to document size, which you should, this O(N^2). Additionally you have high proportionality faction since for every tag you need to test its kind and decode its the attributes. Additionally one must recursively unwind every single nested quotation before proceeding to the next element. If the largest substructure is too large to fit in memory this is going to fall over. If you have relational IDREFs you may have to backtrack for multiple passes. In short you are paying the majority of the penalty of reconstituting the data structure exactly like the OP said.
Now as for "working on the data " not the storage format. Well YAML is structured data too. One is free to traverse its tree as well in exactly the same manner. But because it's storage format is efficiently decodable one does not actually have to instantiate the tree to discover many of its element.
I've noticed that my earthlink connection gets good marks for speed on tests but the speed tests take many seconds to actually start. In deed all my pages seem to load with multiple seconds of latency then all at once. (no it's not the browser, I have multiple computers that I move between home and work so I can do test across different ISPs)
I think what they are doing is giving me 1000KBs at periodic intervals or with a high latency such that my peak speed is high but my average speed is low. My latency for 600 miles connections is a good fraction of a second. Pages that have lots of element load hideously slowly compared to pages with a big download, presumably because I'm paying this huge latency penalty multiple times.
Why oh why do people use XML for data centric, quasi-human readable configuration files when YAML is the ideal solution for this.
I'm looking at the YAML 1.1 specs and don't see anything about schemas or data validation. Am I overlooking something?
Yes you missed a couple things. As you may know XML has had multiple ways to define schema and multiple validators over the years. YAML has validation at several different levels. First in syntax, since there's no close tags one never has a missing close tag to deal with. Simple data types can be declared by !!tags. And More complex structures (i.e. classes) can be declared by the user with local !tags. And of course built in data structures like hashes, arrays and references/pointers are part of the syntax. IN all these cases the document description is really part of the document it self. that is the thing telling you that the next statement is an integer or string or float is in the document it self.
Since yaml has many built in URI (binary, hex, float, hash, ordered hash, array, etc...) plus it has extensible type tags for locally declared types (i.e. classes) that can validate their own attributes. There is not as much desire for a separate schema declaration or validator as there is with XML
However sometimes you still want a schema and validator. For higher order abstraction of the document's expected structure, one can use a different schema validator such as Kwalify which also works for JSON too. Finally, since one can place any XML document into a YAML document simply by indenting it one space--and no other changes at all--, you can always put XML document schema language into a YAML document and use that.
because you don't have to instantiate the multi-megabyte structured data entire file just to grep out one record.
Grepping anything out of even a modestly sophisticated XML document is pretty much unreliable and generally slow. You have to wade through the nested close and open tag, balance all nested quotations, and in many cases worry about the utf encoding. Because XML does not gaurentee the white space things get even weirder.
let's take a for instance. Suppose I was looking for all the hash entries that has the key "highschool". In XML you'd have to worry about all the nested qoutations and then find every key open and close tag, then parse this and find it's content and see if it is "High school". You could not go looking for the word "highschool" because that might be simply text found elsewhere. And you can't look just for tags like "key" because those might be part of some quotations.
In yaml you would grep like this:
grep "^\s*highschool\s*:"
to yank out the all the highschool key value pairs. (If the value might be a multiple line entry a few more items in the regex are needed)
the latter is blaziningly fast.
But really folks, do yourself and the rest of us a favor and read up on JSON and YAML.
(Un)?fortunately, "the rest of us" seems to make up about 5% of the programming population. The rest of the rest of us are using XML.
Right. that's the problem. Need to spread the word. Now you know and you can spread it too.
Actually, after looking at that reference card, YAML is much more complex than I thought it was.. compared to that, XML is simple (provided you ignore all that outdated crap like DTD/Doctype, processing instructions) and just use elements, attributes and built-in entities.
Well good for you, for actually looking. But as you say about XML, most of the time you only use the base elements in YAML too. In YAML those are "-" for arrays, ":" for hashes, and "|" for block quotes. YAML streamlines things even further by getting rid of close-tags and it mostly dispenses with attributes being special data and having to live in tag, and just merges them all into the payload area, putting all data and attributes on equal footing.
But sure I agree YAML does not have a lot of pre-written stuff out there for exploiting it. My original lament was that XML is the default choice when it's a poor choice. For Configuration files, and document headers, and simple output from most programs YAML makes a far superior choice both in human readability and for fast parsing.
These days everything is one library away from being immediately available for use. Since YAML can do everything XML can do, and because it's trivial to insert XML into YAML (but not the reverse), you really could replace XML with it. YAML even handles relational data, something XML has only begun to do.
I'm perpetually surprised every-time I see a new implementation of XML. For example, macintosh plists, many of which replace older ad hoc Unix configs, are in XML. Why oh why do people use XML for data centric, quasi-human readable configuration files when YAML is the ideal solution for this. And for web usage, where perl, python, and ruby abound, why would would people not use YAML since it's so easy to parse with just regular expressions, and because you don't have to instantiate the multi-megabyte structured data entire file just to grep out one record. And in the day of java script and web 2.0, there's JSON. So why does this ponderous obsolete dinosaur XML persist.
Perhaps I'm being too negative here. I sound like a troll. But really folks, do yourself and the rest of us a favor and read up on JSON and YAML. You''ll see I'm being only too kind and generous to YAML.
I think what they are after is a carbon source liquid that releases hydrogen and traps the carbon. THis is presumably to get around the low density of pure hydrogen storage. Perhaps some sort of fuel cell that liberates hydroggen from methane, keeps the carbon and burns the hydreogen. just a guess. low density is a problem both for the cars and for the fueling stations. to top it off liquid handling is easier than gas phase for consumers.
But there's an israeli company with an even better idea.
You use solid magnesium and water. the magnesium a spool of wire that is fed slowly into a bath of water. it reacts to produce hydrogen which bubbles out and into the engine, and also a solid magnesium oxide which sinks and is collected. THe solid magnesium waste is collected, and sent to a plant where it reproccessed back to magnesium metal electochemically, releasing oxygen in the process which itself could be collected for other uses.
IN general apple tends to remove old features/ ports/ connectors when it adds replacements or equalivalents. Apple is a first mover in many areas: parallel ports? ADB, Floppy disks,.... Then it adds them back if there are howls.
It's a good strategy in many ways. First, it allows one to keep the idea that there is one-primary-way-for-novices-to-do-something on most mac. When you go to another mac, it behaves the same. (e.g. Life is a box of chocolates with linux. when you sit down at someone elses terminal, focus might follow the mouse, it might auto-raise, god knows what happens when you launch emacs (xterm or text, context colored or not, etc...) Uniformity is viewed as good mac land because ultimately by not having to think too much or memorize short cuts you can just focus on getting the job done and the computer is more appliance like than tweaker box like. It's not that you can't customize a mac, it's just stupid to try in general.
It also allows them to introduce new lower level mechanism that break old higher level mechanisms. Such as the clean/dirty file tracking used for Time Machine.
I don't know why they deprecated your MP3 file moving. My guess however it was the opposite intent. they were trying to put in speed bumps--apples view of the best DRM seems to be to simply use invoconvience rather than prohibition when they can. I rather like that approach philosophically.
If you accept the arguments here then you must also accept that vegetarianism, as practiced in the west, is even worse for the planet.
Each bite of vegetable travels on average 2000 miles. And the fuel used to power the travel came from even further away.
Vegetarianism requires conversion of forest to crop land which this article points out has a 93 year carbon-debt payback time for fuel production and of course an infinite period payback for growing vegetable since they don't carbon offset anything.
Vegetables use irritation which requires energy to move the water (most large scale irrigation is done in proximity to hydro electric dams for a reason: water+power.
Vegetables use irritation which makes the land salty and eventually depletes the soil.
Plowing weeding planting, ferilizing, storing and drying consume energy. In contrast with beef, the cows are self propelled, and can even deliver themselves to colllection points. 100% of the animal is used. And only the high density nutritious parts have to be shipped.
Beef will graze in forests and other areas without destoying them. They don't need irrigation, there is no huge loss of water to evaporation. No pesticides enter the water stream.
Most beef spends only a short portion of it's life cycle on a feedlot. And feed lot animals produce 1/3 of the methane as grain fed animals. The net methane production of cattle affecting the environment is a flawed notion when you consider there are half as many cows in the US as buffalo that used to roam.
Old folks will recall that the plot of THX-1138 revolved around Criminal Drug Evasion.
There have been proposals for criminal control outside prisons through the use of mood altering drugs. Fun shit like Thorazine that reduces your atention span to less than the guy in Memento, so basically you can't get in to mischief because you'll get completely bored an move on before any harm happens.
The sick part of these proposals were to use RFID labeled pills, so that a relative simple compliance monitoring device could determine if the pill was inside you versus just inside your pocket or in the trash can.
C and C++ can act dynamically typed too. proof: Perl is written in C. perl is dynamically typed. ergo, you can have dynamic typing in C. Albeit by implementing a perl interpreter.
I was not raving about the fact that there's this groovy missingmethod command in perl that nothing else can do. I was raving about the fact that it's just a trivial artifcat of the bless() list. And that is exactly how ruby and python implement it too. it just is not transparent that it's just a trivial artifact of the same feature that gives every other object feature.
first I'll note that since all languages are turing complete any language can do anything. Afterall per is wrttten in C, ergo C can do all that I described.
The point I was making was this. What do the following have in common:
Lisp --everything is a list Prolog --everything is a boolean Haskel --everything is a function Forth --everything goes on the stack APL --everything is a matrix
What these have in common is two things 1) they take one simple idea and see how far you can run with it. And the results are truly amazing actually.
2) they are hard as hell to actually write general programs in.
Real programming languages like python, java, C, C++, fotran 95, D, and so on, combine all those elements in to real languages. They are not trying for computer science purity.
Perls a weird case. Regualr spagetti perl is dogerl of many things and highly useful. THe opposite of a pure language.
But there's an exception to that. Perl Objects.
Perl Objects -- and object is created when any primitive variable (e.g. an integer) has an associated list storage space.
the Bless() command in perl just adds a list attribute to a primitive.
And then look how far you can run with that. Wholly fuck! every single chapter in the python book or a java book talking about some language feature is just a cosnequence of "bless"
classes --- the bless list inheritance --- the bless list Add-ins. --- addingin to the bless list type checking --- inpecting the blessed list column-centric Data bases --- bless....
I've stood up in from of rooms of many year python experts and drawn out how python's syntactic sugar is hiding Bless() and suddenly they have a real understanding of how python actually works, not just how to use it, but how to exploit it.
Don't worry, I have a patent on "method for the prevention of public disclosure of cease and desist letters" in which I describe the use of copyright notices on said letters. I am issuing a cease and desist letter to this lawyer, who is infringing on my patent. The only reason you have not heard of this latest development is that my cease and desist order to him was copyrighted.
The list missed the most important part of perl. A glue language. Python and a few other languages claim they can be glue languages but that's pretty much a joke to anyone who knows both fluently. Perl is the ultimate glue language for combining diverse output so different programs from different sources, written decades apart in different languages can all work like a well oiled machine.
The other really odd experience for me was learing object oriented programming. I had been programming in objects since I was first introduced to them when the first NeXT computer came out. I used java. And C++ and such. I thought I understood objects.
Then one day I learned to program object oriented in Perl. An I learned that while I was fluent in object oriented usage, I really had a pathetic understanding of how they worked and what was actually possible with objects.
Perl objects are sort of like owning a copy of grey's anatomy or "the visible" man. You son't just see that arms connect to torso's from outside but you see all the sinews and bones and blood.
It's actually amazing how so many things we think of as different concepts in object oriented programming and data bases are actually different reflections of the same trick. And that's the trick perl use to make objects.
in perl, an object is any variable that has an attribute that can store a list of package names.
Let's see what you can do with that.
Hmmm.... well that list can be your inheritance heirarchy so each package is what you search for methods. But notice that since it's a mutable list a perl object can do something else that most object oriented languages cannot. A variable can change it's "inheritance" list after the fact. it can change it's own class.
Okay Now this is just a single variable so where to we get attributes of the object? Well, if that variable is say a hash (dictionary) then we can just use the key's as the attribute names. so if were to write self.foo in C++, you would write self->{foo} in perl.
More fun: let's say you call a method() or ask for an attribute on a variable that does not exist. Well, a perl object can just add more packages to it's inheritnace list. Or it cold write the method on the spot and add it too it's own inheritnace. "I'm my own grandpa". I've used this trick many times to create tables. I don't write any of the "get" or "set" methods. instead I just intercept the call to the method "setfoo()" which never existed cause I never wrote it, then I have perl create an attribute called foo: Self->{foo} = "something". then I have perl write a subroutine called "setfoo" and add that subroutine into a package namespace and put that in it's inhereticnace list.. ("like adding methods to a C++ package outside the declaration". (programming tip: obviously this is could lead to problems with typos, so I also provide the variabel with a list of all allowed attribute names--- but of course I can always add to that list later).
Now something more exotic. The hottest thing in Data base programming is the realization that sometimes column centric data bases are better than traditional row-centric data bases structures. In perl an object can change which it is, transparently. For example, if I'm a traditional object with a row organization then all my attributes are stored as self->{foo1}, self->{foo2}, self->{foo3}. and so on, just as you might right self.foo3 in python. But I did not have to do it that way. What if instead of making the self variable a hash (dictionary) I had made the self-variable a simple scalar, say an integer. Well at fist this seems stupid, where did all the instance variables go? Well, I just store them in the class. I make the scalar self-variable's integer just an index. The class keeps the instance variables in arrays--that is column based storage--.. SO for example if self = 4, then the attibute foo for this instance now becomes self->class->foo[4].
I can't give you a technical answer because I don't understand how it works myself. But I can give you an empircial answer. I'm 100% correct. I know this because I've tested it hundreds of times on dozens of different computer architectures. It was in fact driving me nuts that I could discover my network connections to nodes on my cluster that were "off" in the sense of the power switch being off or being in sleep mode. If you walk up to the machines themselves even when they are unplugged you can see the little ethernet LEDs blinking away when they are jacked in. I raised this issue with several different sysadmins. they all laughed and said yep, it that newer NIC actually don't need the computer powered up to respond to signals in minimal ways. You can even take the nic out of the computer and it can still work! Depending on the nic it can be very minimimal or as sophisticated as waiting for a wake on LAN (which I assume is because sleep mode draws some power).
Anyhow it's a fact. You can't always tell if a computer is off by pinging it.
Long haul flights tend to have the 75 watt jacks. By going to the led screen and trimming the cpu speed apple came in under the magic number of 75 watts. According to seat guru not every seat in a plane is equipt, they stagger the jacks so you may have not seen them. Also they are no on the short haul planes (yet). It should be noted that the 5 hour rated life is actually under real world usage conditions: wifi on, screen at half brightness, disk spinning, so your milage may very if you scrimp. On my macbook pro I run with the screen just one click from dark, turn off the wifi and shut down the disk when I can. Also given the 2GB standard memory I expect this puppy will hit the disk a bit less often.
In most major airports I fly into it's no longer neccessary to lie on the floor next to a coveted power jack. There's these (for sale) power stations going in usually run by the smart-cart luggage folks. I expect within the year these will be ubiquitous. Sure you'll drop a few dimes for something you used to get free but you'll have a more assured charging expectation between short hop flights, and probably less expensive than the spare battery you now don't need.
Finally, airlines are now experimenting with a music "charging tone" for the ubiquitous audio jack currently on all seats. It won't be enough to run a 75 watt laptop but it is already good enough to charge up power cells or ipods. So you can see the airlines are going that way.
If you look at history steve always dumps old shit about a year before people think he should, then a year later we see all these companies trying to stretch themselves with backward comaptibility and realizing steve got it right.
examples: How long computers persist in having 5-1/4 or hard shell floppies long after they were not needed. Remember parallel ports and Rs232 serial. THose jacks used to festoon the back of computers long past the point they were needed. PCMCIA is a gonner too, but it still is being built into computers. Modems? would you not rather pay $25 for a usb to modem dongle if you needed rather than have it built in and drawing power. VGA connectors--who needs them--just use a dongle if you want one.
instead with a mac oyu tend to get ubiquitous high level features that software writers can count on being in every new mac for 5 years or so. Like motion sensors, lit keybaords, DVI. Or way back to the apple II , postscript, hard disks, dynamic memory replacing static ram, and optical disks.
The only one that bugs me is the non ubiquitous support of fire wire.
Slashdot Mirror
A lot of truth in what you say. But then if you did do this XML itself just a concrete realization of a database. So why choose something as inefficient as XML? The only time XML has something resembling efficiency that I can see is when the best method for the job is specifically markup in nature. (i.e. text formatting) rather than data serialization.
So I think that answers the question of why XML isn't pure binary. People want the visual attraction of seeing how the DB structures is formed by inspecting the file by hand.
Unless you assume the depth of recursion is not proportional to document size, which you should, this O(N^2). Additionally you have high proportionality faction since for every tag you need to test its kind and decode its the attributes. Additionally one must recursively unwind every single nested quotation before proceeding to the next element. If the largest substructure is too large to fit in memory this is going to fall over. If you have relational IDREFs you may have to backtrack for multiple passes. In short you are paying the majority of the penalty of reconstituting the data structure exactly like the OP said.
Now as for "working on the data " not the storage format. Well YAML is structured data too. One is free to traverse its tree as well in exactly the same manner. But because it's storage format is efficiently decodable one does not actually have to instantiate the tree to discover many of its element.
Seriously dude, don't disparage efficient coding.
I've noticed that my earthlink connection gets good marks for speed on tests but the speed tests take many seconds to actually start. In deed all my pages seem to load with multiple seconds of latency then all at once. (no it's not the browser, I have multiple computers that I move between home and work so I can do test across different ISPs)
I think what they are doing is giving me 1000KBs at periodic intervals or with a high latency such that my peak speed is high but my average speed is low. My latency for 600 miles connections is a good fraction of a second. Pages that have lots of element load hideously slowly compared to pages with a big download, presumably because I'm paying this huge latency penalty multiple times.
nice post.
I'm looking at the YAML 1.1 specs and don't see anything about schemas or data validation. Am I overlooking something?
because you don't have to instantiate the multi-megabyte structured data entire file just to grep out one record.Yes you missed a couple things. As you may know XML has had multiple ways to define schema and multiple validators over the years. YAML has validation at several different levels. First in syntax, since there's no close tags one never has a missing close tag to deal with. Simple data types can be declared by !!tags. And More complex structures (i.e. classes) can be declared by the user with local !tags. And of course built in data structures like hashes, arrays and references/pointers are part of the syntax. IN all these cases the document description is really part of the document it self. that is the thing telling you that the next statement is an integer or string or float is in the document it self.
Since yaml has many built in URI (binary, hex, float, hash, ordered hash, array, etc...) plus it has extensible type tags for locally declared types (i.e. classes) that can validate their own attributes. There is not as much desire for a separate schema declaration or validator as there is with XML
However sometimes you still want a schema and validator. For higher order abstraction of the document's expected structure, one can use a different schema validator such as Kwalify which also works for JSON too. Finally, since one can place any XML document into a YAML document simply by indenting it one space--and no other changes at all--, you can always put XML document schema language into a YAML document and use that.
You don't have to do that with XML, either. You can, but you don't have to.
Grepping anything out of even a modestly sophisticated XML document is pretty much unreliable and generally slow. You have to wade through the nested close and open tag, balance all nested quotations, and in many cases worry about the utf encoding. Because XML does not gaurentee the white space things get even weirder.let's take a for instance. Suppose I was looking for all the hash entries that has the key "highschool". In XML you'd have to worry about all the nested qoutations and then find every key open and close tag, then parse this and find it's content and see if it is "High school". You could not go looking for the word "highschool" because that might be simply text found elsewhere. And you can't look just for tags like "key" because those might be part of some quotations.
In yaml you would grep like this:
grep "^\s*highschool\s*:"
to yank out the all the highschool key value pairs. (If the value might be a multiple line entry a few more items in the regex are needed)
the latter is blaziningly fast. But really folks, do yourself and the rest of us a favor and read up on JSON and YAML.
(Un)?fortunately, "the rest of us" seems to make up about 5% of the programming population. The rest of the rest of us are using XML.
Right. that's the problem. Need to spread the word. Now you know and you can spread it too.Well good for you, for actually looking. But as you say about XML, most of the time you only use the base elements in YAML too. In YAML those are "-" for arrays, ":" for hashes, and "|" for block quotes. YAML streamlines things even further by getting rid of close-tags and it mostly dispenses with attributes being special data and having to live in tag, and just merges them all into the payload area, putting all data and attributes on equal footing.
Here's another document to look at that's a great 1-page introduction to YAML in action.
But sure I agree YAML does not have a lot of pre-written stuff out there for exploiting it. My original lament was that XML is the default choice when it's a poor choice. For Configuration files, and document headers, and simple output from most programs YAML makes a far superior choice both in human readability and for fast parsing.
Beautifully said.
I think you answered the question. Yes. for many uses being able to use a simple text editor is great.
Have a look sometime at the yaml documetnation quick reference-card : it's written in YAML and fits on one page. That's how compact yet human readable it is, try that in XML.
These days everything is one library away from being immediately available for use. Since YAML can do everything XML can do, and because it's trivial to insert XML into YAML (but not the reverse), you really could replace XML with it. YAML even handles relational data, something XML has only begun to do.
Perhaps I'm being too negative here. I sound like a troll. But really folks, do yourself and the rest of us a favor and read up on JSON and YAML. You''ll see I'm being only too kind and generous to YAML.
Link. also google for magnesium hydrogen car and you'll also find other companies.
I think what they are after is a carbon source liquid that releases hydrogen and traps the carbon. THis is presumably to get around the low density of pure hydrogen storage. Perhaps some sort of fuel cell that liberates hydroggen from methane, keeps the carbon and burns the hydreogen. just a guess. low density is a problem both for the cars and for the fueling stations. to top it off liquid handling is easier than gas phase for consumers.
But there's an israeli company with an even better idea.
You use solid magnesium and water. the magnesium a spool of wire that is fed slowly into a bath of water. it reacts to produce hydrogen which bubbles out and into the engine, and also a solid magnesium oxide which sinks and is collected. THe solid magnesium waste is collected, and sent to a plant where it reproccessed back to magnesium metal electochemically, releasing oxygen in the process which itself could be collected for other uses.
It's not free. It's built into the price of the handset/subscription.
IN general apple tends to remove old features/ ports/ connectors when it adds replacements or equalivalents. Apple is a first mover in many areas: parallel ports? ADB, Floppy disks, ....
Then it adds them back if there are howls.
It's a good strategy in many ways. First, it allows one to keep the idea that there is one-primary-way-for-novices-to-do-something on most mac. When you go to another mac, it behaves the same. (e.g. Life is a box of chocolates with linux. when you sit down at someone elses terminal, focus might follow the mouse, it might auto-raise, god knows what happens when you launch emacs (xterm or text, context colored or not, etc...) Uniformity is viewed as good mac land because ultimately by not having to think too much or memorize short cuts you can just focus on getting the job done and the computer is more appliance like than tweaker box like. It's not that you can't customize a mac, it's just stupid to try in general.
It also allows them to introduce new lower level mechanism that break old higher level mechanisms. Such as the clean/dirty file tracking used for Time Machine.
I don't know why they deprecated your MP3 file moving. My guess however it was the opposite intent. they were trying to put in speed bumps--apples view of the best DRM seems to be to simply use invoconvience rather than prohibition when they can. I rather like that approach philosophically.
If you accept the arguments here then you must also accept that vegetarianism, as practiced in the west, is even worse for the planet.
Each bite of vegetable travels on average 2000 miles. And the fuel used to power the travel came from even further away.
Vegetarianism requires conversion of forest to crop land which this article points out has a 93 year carbon-debt payback time for fuel production and of course an infinite period payback for growing vegetable since they don't carbon offset anything.
Vegetables use irritation which requires energy to move the water (most large scale irrigation is done in proximity to hydro electric dams for a reason: water+power.
Vegetables use irritation which makes the land salty and eventually depletes the soil.
Plowing weeding planting, ferilizing, storing and drying consume energy. In contrast with beef, the cows are self propelled, and can even deliver themselves to colllection points. 100% of the animal is used. And only the high density nutritious parts have to be shipped.
Beef will graze in forests and other areas without destoying them. They don't need irrigation, there is no huge loss of water to evaporation. No pesticides enter the water stream.
Most beef spends only a short portion of it's life cycle on a feedlot. And feed lot animals produce 1/3 of the methane as grain fed animals. The net methane production of cattle affecting the environment is a flawed notion when you consider there are half as many cows in the US as buffalo that used to roam.
Old folks will recall that the plot of THX-1138 revolved around Criminal Drug Evasion.
There have been proposals for criminal control outside prisons through the use of mood altering drugs. Fun shit like Thorazine that reduces your atention span to less than the guy in Memento, so basically you can't get in to mischief because you'll get completely bored an move on before any harm happens.
The sick part of these proposals were to use RFID labeled pills, so that a relative simple compliance monitoring device could determine if the pill was inside you versus just inside your pocket or in the trash can.
In other words THX-1138. Busted for drug evasion.
Yep, iphones will be 4G so don't buy one now, wait till they are even better.
Their going to call it the "PocketFire"
C and C++ can act dynamically typed too.
proof: Perl is written in C. perl is dynamically typed. ergo, you can have dynamic typing in C. Albeit by implementing a perl interpreter.
I was not raving about the fact that there's this groovy missingmethod command in perl that nothing else can do. I was raving about the fact that it's just a trivial artifcat of the bless() list. And that is exactly how ruby and python implement it too. it just is not transparent that it's just a trivial artifact of the same feature that gives every other object feature.
it's not even restricted to dynamic typing.
I think you missed the point.
....
first I'll note that since all languages are turing complete any language can do anything. Afterall per is wrttten in C, ergo C can do all that I described.
The point I was making was this. What do the following have in common:
Lisp --everything is a list
Prolog --everything is a boolean
Haskel --everything is a function
Forth --everything goes on the stack
APL --everything is a matrix
What these have in common is two things
1) they take one simple idea and see how far you can run with it. And the results are truly amazing actually.
2) they are hard as hell to actually write general programs in.
Real programming languages like python, java, C, C++, fotran 95, D, and so on, combine all those elements in to real languages. They are not trying for computer science purity.
Perls a weird case. Regualr spagetti perl is dogerl of many things and highly useful. THe opposite of a pure language.
But there's an exception to that. Perl Objects.
Perl Objects -- and object is created when any primitive variable (e.g. an integer) has an associated list storage space.
the Bless() command in perl just adds a list attribute to a primitive.
And then look how far you can run with that. Wholly fuck! every single chapter in the python book or a java book talking about some language feature is just a cosnequence of "bless"
classes --- the bless list
inheritance --- the bless list
Add-ins. --- addingin to the bless list
type checking --- inpecting the blessed list
column-centric Data bases --- bless
I've stood up in from of rooms of many year python experts and drawn out how python's syntactic sugar is hiding Bless() and suddenly they have a real understanding of how python actually works, not just how to use it, but how to exploit it.
Don't worry, I have a patent on "method for the prevention of public disclosure of cease and desist letters" in which I describe the use of copyright notices on said letters. I am issuing a cease and desist letter to this lawyer, who is infringing on my patent. The only reason you have not heard of this latest development is that my cease and desist order to him was copyrighted.
The list missed the most important part of perl. A glue language. Python and a few other languages claim they can be glue languages but that's pretty much a joke to anyone who knows both fluently. Perl is the ultimate glue language for combining diverse output so different programs from different sources, written decades apart in different languages can all work like a well oiled machine.
The other really odd experience for me was learing object oriented programming. I had been programming in objects since I was first introduced to them when the first NeXT computer came out. I used java. And C++ and such. I thought I understood objects.
Then one day I learned to program object oriented in Perl. An I learned that while I was fluent in object oriented usage, I really had a pathetic understanding of how they worked and what was actually possible with objects.
Perl objects are sort of like owning a copy of grey's anatomy or "the visible" man. You son't just see that arms connect to torso's from outside but you see all the sinews and bones and blood.
It's actually amazing how so many things we think of as different concepts in object oriented programming and data bases are actually different reflections of the same trick. And that's the trick perl use to make objects.
in perl, an object is any variable that has an attribute that can store a list of package names.
Let's see what you can do with that.
Hmmm.... well that list can be your inheritance heirarchy so each package is what you search for methods. But notice that since it's a mutable list a perl object can do something else that most object oriented languages cannot. A variable can change it's "inheritance" list after the fact. it can change it's own class.
Okay Now this is just a single variable so where to we get attributes of the object? Well, if that variable is say a hash (dictionary) then we can just use the key's as the attribute names. so if were to write self.foo in C++, you would write self->{foo} in perl.
More fun: let's say you call a method() or ask for an attribute on a variable that does not exist. Well, a perl object can just add more packages to it's inheritnace list. Or it cold write the method on the spot and add it too it's own inheritnace. "I'm my own grandpa". I've used this trick many times to create tables. I don't write any of the "get" or "set" methods. instead I just intercept the call to the method "setfoo()" which never existed cause I never wrote it, then I have perl create an attribute called foo: Self->{foo} = "something". then I have perl write a subroutine called "setfoo" and add that subroutine into a package namespace and put that in it's inhereticnace list.. ("like adding methods to a C++ package outside the declaration". (programming tip: obviously this is could lead to problems with typos, so I also provide the variabel with a list of all allowed attribute names--- but of course I can always add to that list later).
Now something more exotic. The hottest thing in Data base programming is the realization that sometimes column centric data bases are better than traditional row-centric data bases structures. In perl an object can change which it is, transparently. For example, if I'm a traditional object with a row organization then all my attributes are stored as self->{foo1}, self->{foo2}, self->{foo3}. and so on, just as you might right self.foo3 in python. But I did not have to do it that way. What if instead of making the self variable a hash (dictionary) I had made the self-variable a simple scalar, say an integer. Well at fist this seems stupid, where did all the instance variables go? Well, I just store them in the class. I make the scalar self-variable's integer just an index. The class keeps the instance variables in arrays--that is column based storage--.. SO for example if self = 4, then the attibute foo for this instance now becomes self->class->foo[4].
The beauty of this is that si
Windows 7 will remind us all of the movie Seven.
We'll have
glutinous Bloatware
Sloth
greedy pricing
DRM lustfully controlling all media.
Proud non-interoperability
and mac -envy
oh and you get the wrath, like in the movie ending where you find can't take back what is in "the box" because you opened the EULA.
Balmer will play the Kevin Spacey role.
personally I had to leave the theater.
I can't give you a technical answer because I don't understand how it works myself. But I can give you an empircial answer. I'm 100% correct. I know this because I've tested it hundreds of times on dozens of different computer architectures. It was in fact driving me nuts that I could discover my network connections to nodes on my cluster that were "off" in the sense of the power switch being off or being in sleep mode. If you walk up to the machines themselves even when they are unplugged you can see the little ethernet LEDs blinking away when they are jacked in. I raised this issue with several different sysadmins. they all laughed and said yep, it that newer NIC actually don't need the computer powered up to respond to signals in minimal ways. You can even take the nic out of the computer and it can still work! Depending on the nic it can be very minimimal or as sophisticated as waiting for a wake on LAN (which I assume is because sleep mode draws some power).
Anyhow it's a fact. You can't always tell if a computer is off by pinging it.
These days most network cards can auto-respond even if the computer is sleeping. So just because you can ping does not mean the computer is on.
Long haul flights tend to have the 75 watt jacks. By going to the led screen and trimming the cpu speed apple came in under the magic number of 75 watts. According to seat guru not every seat in a plane is equipt, they stagger the jacks so you may have not seen them. Also they are no on the short haul planes (yet). It should be noted that the 5 hour rated life is actually under real world usage conditions: wifi on, screen at half brightness, disk spinning, so your milage may very if you scrimp. On my macbook pro I run with the screen just one click from dark, turn off the wifi and shut down the disk when I can. Also given the 2GB standard memory I expect this puppy will hit the disk a bit less often.
In most major airports I fly into it's no longer neccessary to lie on the floor next to a coveted power jack. There's these (for sale) power stations going in usually run by the smart-cart luggage folks. I expect within the year these will be ubiquitous. Sure you'll drop a few dimes for something you used to get free but you'll have a more assured charging expectation between short hop flights, and probably less expensive than the spare battery you now don't need.
Finally, airlines are now experimenting with a music "charging tone" for the ubiquitous audio jack currently on all seats. It won't be enough to run a 75 watt laptop but it is already good enough to charge up power cells or ipods. So you can see the airlines are going that way.
If you look at history steve always dumps old shit about a year before people think he should, then a year later we see all these companies trying to stretch themselves with backward comaptibility and realizing steve got it right.
examples: How long computers persist in having 5-1/4 or hard shell floppies long after they were not needed. Remember parallel ports and Rs232 serial. THose jacks used to festoon the back of computers long past the point they were needed. PCMCIA is a gonner too, but it still is being built into computers. Modems? would you not rather pay $25 for a usb to modem dongle if you needed rather than have it built in and drawing power. VGA connectors--who needs them--just use a dongle if you want one.
instead with a mac oyu tend to get ubiquitous high level features that software writers can count on being in every new mac for 5 years or so. Like motion sensors, lit keybaords, DVI. Or way back to the apple II , postscript, hard disks, dynamic memory replacing static ram, and optical disks.
The only one that bugs me is the non ubiquitous support of fire wire.