C#'s "using (...) {... }" clause provides the same functionality. Garbage collection doesn't get in the way.
C++ RAII-style code is implemented using C++'s object destruction rules. Obviously, the same implementation wont work for a language with different object destruction rules. However, the same feature can be implemented differently (as it has been in C#).
Since (efficient) GCs are non-deterministic and lock-the-world, if you wanted to run the code when an object is deleted, you'd have to be non-deterministic (ie you couldn't batch up deletions which is one of GCs performance advantages)
GCs batch up the freeing of memory. It could run destructor code deterministically and still wait until later to free the memory. The problem is figuring out when to run destructor code.
... predictable memory management can be used for controlling access to files and similar resources, creating safer thread locking code and even providing better error messages.
You're listing things that can be made easier with the C++ RAII idiom. This has nothing to do with garbage collection. C#'s "using (...) {... }" construct does what you're asking for. The only difference is that the scope is more explicit (which was a conscious design decision, not a constraint imposed by garbage collection).
They basicly give you all the functionality of multiple inheritance without a lot of the mess it can cause.
If you replace "basicly" [sic] with "don't", that sentence would be correct. Mixins get you closer (and possibly close enough).
Also, I wouldn't consider Java and C# to be completely type safe. From a security perspective, sure... all unsafe operations will be checked at runtime. But from a program development point of view, using C# or Java doesn't guarantee that your code will not generate a ClassCastException or NullPointerException. Those are type errors caused by the use of the unsafe type case (which is hidden/implicit in the case of NullPointerException). Both of these could have been entirely avoided had the language been designed better.
Static classes have many uses - you can use them to represent a singleton object, or you can encapsulate, non-object specific operations. Like everying in System.Math for example. Not everything is best represented as an object - Microsoft is pragmatic enough to recognize that, even if some object-oriented bigots don't or won't.
(By "static classes", I assume you're referring to classes whose methods are static.)
Static methods are a hack. They are only necessary because some idiot decided that only classes could exist at the top level. If objects could exist at the top level, singletons could be defined more naturally. If functions could exist at the top level, the math functions could be defined more naturally as functions in the "Math" namespace.
Someone should point out, though, that static classes weren't invented by Microsoft. They existed in C++ but only fully assumed their current role with the introduction of Java (because C++ lets you use top-level functions and objects they are appropriate).
Agree. Most colleges in India use English as the medium of instruction. Until recently, anyone who has had to deal with a computer was probably relatively fluent in English so there was never an urgent need to deal with internationalization.
It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?
Yes it does. Haven't you ever read a datasheet that revealed something cool about the way a device works?
Sometimes, for performance reasons, the device interface cannot be too abstract. The API will often end up mirroring a device's internal architecture, possibly exposing something novel that competitors haven't figured out yet. Nat Friedman, in an interview, commented on how graphics card manufacturers are understandably reluctant about providing open source drivers because more and more magic is being done in software.
One possible solution would be to move the magic into the firmware (though some people would consider this unacceptable) and present an abstraction to the OS driver. This might work. Then again, this might be just as inefficient as creating the abstraction in hardware.
Another solution would be to make it easy for vendors to ship binary-only drivers. You don't even really need a completely stable ABI for this, because companies like NVidia get by fine with their compilable wrappers around binary drivers. Dell's DKMS might help out here.
Does linux have fine-grained locking in its kernel?
Yes. Linux started moving away from the BKL long ago (which, according to Siracusa, is a new development in Tiger). Linux scales along the processor axis and process/thread axis, and latency is getting lower all the time. I don't see Mac OS X being used in 8-way configurations. The article benchmarks provides some evidence that OS X can't handle as many processes/threads as Linux and has higher latency than Linux (signal handling benchmark).
Does linux have or support Access Control Lists?
Yes. Not only does it have them, it supports them as well.
Well yes and no. It depends on whether or not you consider teh first assignment to a variable to be it's declaration. If not then no, you don't need to declarare the variable either.
What do you mean? A declaration gives a variable scope. Listing a named function parameter is a declaration. Using a variable in a "let" is a declaration.
But this feature is highly convenient...
For example, I can get it to print out any variable using "say ".
That's it. Same for literal text enclosed in quotes or whatever.
The fact that you don't have to declare variables has nothing to do with "say".
Not like C where I _have_ to f**king format even a plain decimal for printing.
I mean, why do I have to go
printf("%d", mynumber);
when there really is only one bloody way to print a decimal? Stupid for a scripting language anyways.
Because the variable is not a "decimal" variable. It's a number. There is more than one way to print a number. That said, 'printf' is totally retarded.
Keep in mind this is a _scripting_ language, it is not compiled and is interpreted at run-time. Having to declare and type your variables would be a waste of time.
Requiring variable declarations lets you catch more errors than you would otherwise catch. Now the extra effort may not be worth it, but from a user's perspective, compiled vs. interpreted has nothing to do with it.
Go take a gander at languages like Haskell, which don't require you to needlessly pre-declare your variables.
You don't have to say what type your variables are, but you do have to declare them. In a purely functional language, every assignment to a variable is a declaration.
And it's not about type safely, it's about variable use safety and being explicit about scope.
They do predictive prefeching of pages. That's probably why they said it's primarily for broadband users. Though they might use their servers for this as well, predictive prefetching can be done entirely locally.
Apparently Mozilla/Firefox already does some prefetching, but the web page author needs to be explicit about what URLs to prefetch. Since the core functionality is already in there, it might be easy to write an extension to prefetch links as well.
So, Declaritive typing for relatively straightforward things is good?
Yes, programming declaratively (when you can) has many benefits over programming operationally. But remember that DTD, while declarative, isn't the most powerful declarative type system. Like you said, it can't handle multiple similar versions efficiently.
And remember, I'm not saying that you must use DTD. If it's not convenient, don't use it. I only brought this up to demonstrate that you can't use DTD to validate your plist XML data (in response to someone saying that using plist XML gives you validation for free).
In a similar fashion either a dozen different DTDs for different flavors of bundles (apps, frameworks, plugins, widgets, etc...) Or one master DTD that needs to flex with a root element based upon bundle type..
Well, you can either write a declarative specification for every single type, or you can write code to manually validate every single type. Take your pick. Though DTD has its problems, this isn't one of them.
And their plist API now gets a boost from XML as it can programatically work with the structure while relying on deeper, public and more tested XML libs to deal with common parsing.
Their plist API gets no benefit, but I think you meant plist implementation. Old-style plists already have a well-tested parser (which, I'm guessing, they still have to support).
Besides, writing a parser is the uncommon case. You essentially only have to do it once. Writing and reading plists is an overwhelmingly more common case. I think the imbalance is high enough to warrant an specialized syntax for plists that is more readable (old-style plists) and efficient (binary plists). XML is neither (and, in fact, worse than old-style plists on both counts).
Also, parsing old-style plists is very easy. Sure, an XML library will let you avoid dealing with the low-level tokenizing details, but it's nothing that a 100-line Lex file couldn't handle for you. Now that I think about it, it might even be less work to parse old-style plists directly than to interface with an XML library and parse plist XML.
And from the App's perspective, they just ask for a key value and get their contructed object data.
Even with the old format, the App's perspective is the exact same. Why do you keep talking about how plists are so great? The question here is whether plist XML is better than the old plist syntax (and answer no:).
It seems to me like Apple got what they needed out of the format. And most of the inefficiencies in the format fall into statistical gaps in the modern computer. Bigger file size? It's still under the minimum 4k allocation per file. Longer processing time? my computer still boots into MacOS X faster and does more than my older computers.
The only thing they got was Unicode, which could have been trivially added to the old plist format. I agree that the performance degredation is tiny, but relative to the benefit (zero), it is infinite.
Format was arcane before, and while wordier now, there's more tools in the forms of syntax hilighting and checking text editors that can help cut down mistakes.
Not only wordier, but less readable. Because of the way Apple designed the format the only thing XML tools can do is try to offset the overhead created by XML in the first place. It's a net loss.
Think about what would happen if C++ was written in XML form. It might look something like this pile of crap. Would you rather edit that stuff in an XML editor or edit C++ in a text editor? It doesn't matter how good your
I will admit that I wasn't the clearest. However, if you use XML as you suggested. Then for each version of your program which adds preferences you need a new DTD in order for you to fully validate. Since a program should be able to handle all versions of its preferences. You now need to check against multiple DTDs.
That is correct. If your preference parsing code needs to be that flexible, then I don't know of any current XML typing system that can handle it (DTD, Schema, Relax NG, etc). Thats why you shouldn't use one.
If I turn off the validator... well that seems to go counter to your desire to validate against the DTD.
My desire to use a form of declarative typing only applies if you can use declarative typing. If you feel you need things to be more flexible and are willing to check everything operationally, then check the XML directly. Property list XML creates an entire layer on top of plain XML and then uses a DTD to validate that extra layer. It's a zero-sum setup. All they added was overhead.
I admit that if the storage was at least an isolated component, it could spit out arbitrary XML. But it would be a lot harder to find the right DTD.
I'm not sure what you mean. If you're going to use arbitrary XML, why would you need a DTD?
Side question: Hmm, does an XML DTD itself even state what a value of a field should be, or is it always tags about strings? The property list DTD at least has a description for each value of whether it's a string, array, int, hash (dictionary), or boolean.
I don't think DTD allows this, but XML Schema or Relax NG might.
I decided to go with an Apple Property List in a cross-platform program, without using Apple's Preferences API, because I wanted better preferences than a memory dump. (what my program had been doing.) Because I wanted them human readable. And because I wanted room for growth without having to flex the DTD for every internal and external release of the program.
The original format was much simpler to read and parse. In your case, you can claim that you didn't feel like writing a parser for the original format (even though I guarantee you could have done it in less than a day) and wanted to use an off-the-shelf XML parser. Apple, however, already has a working parser. There was no reason for them to create the property list XML format.
I'm no XML God, but just a young programmer. And what Apple was doing with the property lists made a heck of a lot more sense than anything else I had seen. And most likely much more sense than anything I could design as well.
Please read my post. I'm not saying property lists suck. I'm saying property list XML is pointless.
The ASCII format is great, so why would you want an XML format?
Because ASCII doesn't support Unicode characters.
That is true. But I think it would have been a much better idea to simply transition to UTF-8 (or to specify the encoding at the top).
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
So, you'd prefer to have DTDs for every item that you want to manage with launchd? I wouldn't.
Not sure what you mean here. If you chose to go the DTD route, youd only have a DTD for every type of launchd config file, not for every program you want to launch.
The problem is this resulted in a preferences system where it was hard to make changes. Add a preference? You now need to change the schema parsing and the schema. And now you need to grok both the old schema and the new one.
To me, your schema seems like an ideal location to enumerate and document your preferences. But let's say you don't give a crap about that; you want to add new preferences by updating the config-file-loading code, but the validator isn't letting your new tags through. Turn off the validator. You don't need it. Just let your config-file-loading code look directly at the XML and take the elements it wants. (BTW, what do you mean by "schema parsing"?)
Atop of that, the bottom most systems (The ones actually taking preferences and storing and loading them) have no real need to know what is being stored. All they need to do is hold onto the data and load/store/return it when requested.
Correct. And so why can't you just give the storage layer arbitrary XML and tell it to store that? Why have the extra layer of indirection ("dict", "array", etc.)?
People (like you and the guys at Apple) are building generic layers on top of XML and building their domain-specific data types on top of that new layer. XML was supposed to be that generic layer, but you guys have implicitly decided that XML sucks too hard to serve that purpose. I totally agree.
First of all, I'm not saying that property lists themselves are bad. I'm just saying that the old format is more readable and property list XML is useless. The rest of my post focused on preempting arguments that might claim that the use of XML gives you additional functionality for free (which may be valid in some situations, but not this one).
You can ensure that the file is a valid property list XML file, but you can't make sure that it contains launchd configuration info.
Of course you can. A launchd configuration property list de-serializes to a CFDictionary. If the CFDictionary doesn't include the required key-value pairs, it's not a valid launchd configuration file.
I meant to say that you can't leverage the DTD/Schema stuff to perform validation. (The line above the one you quoted was indented to establish that, but I suppose I probably should have ended it with a colon, huh?) And, like you said, you can do all your validation operationally if you want. Or you could create a declarative system just for property lists. But you can't leverage existing DTD/Schema libraries to handle this for you.
DTD/Schema sensitive editors still wont help you out with semantic structure.
Technically this is a valid point, I agree. But property lists are almost always so incredibly simple that this objection is purely academic.
Well, if you don't need editor support, that's great. And it just may be the case that nobody will ever want code-completion-like editor support when editing your configuration files, but I doubt it. You can create a custom editor that understands your custom declarative type system for property lists -- and that's perfectly fine -- but the use of XML achieves nothing here (just decreased readability and a slight performance degredation).
I am aware of property lists. The post I responded to was talking about XML in general and not about property lists. My other post explains why property list XML is a stupid idea.
I totally agree that it sucks having to learn many formats, especially when the difference is arbitrary. However, the reason people object to XML is that it's a really bad format.
What? A concession? I though all you XML haters didn't think XML was good for ANYTHING? Every story that even mentions XML in passing, bring you all out in force. You all should incorperate. At least become a tax-deductiable organization or something.
Haha. I didn't know we looked like that. Wasn't it the pro-XML people that were the rabbid ones? I wonder when the tables turned.
In my defence, I was only responding to a very pro-XML comment. The again, the guy who brought XML up in the first place was a member of "our" camp, I suppose.
Slashdot Mirror
C#'s "using (...) { ... }" clause provides the same functionality. Garbage collection doesn't get in the way.
C++ RAII-style code is implemented using C++'s object destruction rules. Obviously, the same implementation wont work for a language with different object destruction rules. However, the same feature can be implemented differently (as it has been in C#).
GCs batch up the freeing of memory. It could run destructor code deterministically and still wait until later to free the memory. The problem is figuring out when to run destructor code.
You're listing things that can be made easier with the C++ RAII idiom. This has nothing to do with garbage collection. C#'s "using (...) { ... }" construct does what you're asking for. The only difference is that the scope is more explicit (which was a conscious design decision, not a constraint imposed by garbage collection).
If you replace "basicly" [sic] with "don't", that sentence would be correct. Mixins get you closer (and possibly close enough).
Also, I wouldn't consider Java and C# to be completely type safe. From a security perspective, sure... all unsafe operations will be checked at runtime. But from a program development point of view, using C# or Java doesn't guarantee that your code will not generate a ClassCastException or NullPointerException. Those are type errors caused by the use of the unsafe type case (which is hidden/implicit in the case of NullPointerException). Both of these could have been entirely avoided had the language been designed better.
(By "static classes", I assume you're referring to classes whose methods are static.)
Static methods are a hack. They are only necessary because some idiot decided that only classes could exist at the top level. If objects could exist at the top level, singletons could be defined more naturally. If functions could exist at the top level, the math functions could be defined more naturally as functions in the "Math" namespace.
Someone should point out, though, that static classes weren't invented by Microsoft. They existed in C++ but only fully assumed their current role with the introduction of Java (because C++ lets you use top-level functions and objects they are appropriate).
I hope the app really works as well as the demo shows.
Agree. Most colleges in India use English as the medium of instruction. Until recently, anyone who has had to deal with a computer was probably relatively fluent in English so there was never an urgent need to deal with internationalization.
Yes it does. Haven't you ever read a datasheet that revealed something cool about the way a device works?
Sometimes, for performance reasons, the device interface cannot be too abstract. The API will often end up mirroring a device's internal architecture, possibly exposing something novel that competitors haven't figured out yet. Nat Friedman, in an interview, commented on how graphics card manufacturers are understandably reluctant about providing open source drivers because more and more magic is being done in software.
One possible solution would be to move the magic into the firmware (though some people would consider this unacceptable) and present an abstraction to the OS driver. This might work. Then again, this might be just as inefficient as creating the abstraction in hardware.
Another solution would be to make it easy for vendors to ship binary-only drivers. You don't even really need a completely stable ABI for this, because companies like NVidia get by fine with their compilable wrappers around binary drivers. Dell's DKMS might help out here.Hmm...adding additional data to an existing archive. I guess that's just about as good as creating Unix, give or take.
The worst was when IE and Navigator would continually fight over naming HTML documents "Microsoft Web Document" (?) vs. "Netscape Hypertext Document".
What do you mean? A declaration gives a variable scope. Listing a named function parameter is a declaration. Using a variable in a "let" is a declaration.
The fact that you don't have to declare variables has nothing to do with "say".
Because the variable is not a "decimal" variable. It's a number. There is more than one way to print a number. That said, 'printf' is totally retarded.
Requiring variable declarations lets you catch more errors than you would otherwise catch. Now the extra effort may not be worth it, but from a user's perspective, compiled vs. interpreted has nothing to do with it.
You don't have to say what type your variables are, but you do have to declare them. In a purely functional language, every assignment to a variable is a declaration.
And it's not about type safely, it's about variable use safety and being explicit about scope.No, you don't always need to declare the type of a variable, but you do need to declare the variable.
They do predictive prefeching of pages. That's probably why they said it's primarily for broadband users. Though they might use their servers for this as well, predictive prefetching can be done entirely locally.
Apparently Mozilla/Firefox already does some prefetching, but the web page author needs to be explicit about what URLs to prefetch. Since the core functionality is already in there, it might be easy to write an extension to prefetch links as well.Yes, programming declaratively (when you can) has many benefits over programming operationally. But remember that DTD, while declarative, isn't the most powerful declarative type system. Like you said, it can't handle multiple similar versions efficiently.
And remember, I'm not saying that you must use DTD. If it's not convenient, don't use it. I only brought this up to demonstrate that you can't use DTD to validate your plist XML data (in response to someone saying that using plist XML gives you validation for free).
Well, you can either write a declarative specification for every single type, or you can write code to manually validate every single type. Take your pick. Though DTD has its problems, this isn't one of them.
Their plist API gets no benefit, but I think you meant plist implementation. Old-style plists already have a well-tested parser (which, I'm guessing, they still have to support).
Besides, writing a parser is the uncommon case. You essentially only have to do it once. Writing and reading plists is an overwhelmingly more common case. I think the imbalance is high enough to warrant an specialized syntax for plists that is more readable (old-style plists) and efficient (binary plists). XML is neither (and, in fact, worse than old-style plists on both counts).
Also, parsing old-style plists is very easy. Sure, an XML library will let you avoid dealing with the low-level tokenizing details, but it's nothing that a 100-line Lex file couldn't handle for you. Now that I think about it, it might even be less work to parse old-style plists directly than to interface with an XML library and parse plist XML.
Even with the old format, the App's perspective is the exact same. Why do you keep talking about how plists are so great? The question here is whether plist XML is better than the old plist syntax (and answer no :).
The only thing they got was Unicode, which could have been trivially added to the old plist format. I agree that the performance degredation is tiny, but relative to the benefit (zero), it is infinite.
Not only wordier, but less readable. Because of the way Apple designed the format the only thing XML tools can do is try to offset the overhead created by XML in the first place. It's a net loss.
Think about what would happen if C++ was written in XML form. It might look something like this pile of crap. Would you rather edit that stuff in an XML editor or edit C++ in a text editor? It doesn't matter how good your
That is correct. If your preference parsing code needs to be that flexible, then I don't know of any current XML typing system that can handle it (DTD, Schema, Relax NG, etc). Thats why you shouldn't use one.
My desire to use a form of declarative typing only applies if you can use declarative typing. If you feel you need things to be more flexible and are willing to check everything operationally, then check the XML directly. Property list XML creates an entire layer on top of plain XML and then uses a DTD to validate that extra layer. It's a zero-sum setup. All they added was overhead.
I'm not sure what you mean. If you're going to use arbitrary XML, why would you need a DTD?
I don't think DTD allows this, but XML Schema or Relax NG might.
The original format was much simpler to read and parse. In your case, you can claim that you didn't feel like writing a parser for the original format (even though I guarantee you could have done it in less than a day) and wanted to use an off-the-shelf XML parser. Apple, however, already has a working parser. There was no reason for them to create the property list XML format.
Please read my post. I'm not saying property lists suck. I'm saying property list XML is pointless.
That is true. But I think it would have been a much better idea to simply transition to UTF-8 (or to specify the encoding at the top).
Not sure what you mean here. If you chose to go the DTD route, youd only have a DTD for every type of launchd config file, not for every program you want to launch.
To me, your schema seems like an ideal location to enumerate and document your preferences. But let's say you don't give a crap about that; you want to add new preferences by updating the config-file-loading code, but the validator isn't letting your new tags through. Turn off the validator. You don't need it. Just let your config-file-loading code look directly at the XML and take the elements it wants. (BTW, what do you mean by "schema parsing"?)
Correct. And so why can't you just give the storage layer arbitrary XML and tell it to store that? Why have the extra layer of indirection ("dict", "array", etc.)?
People (like you and the guys at Apple) are building generic layers on top of XML and building their domain-specific data types on top of that new layer. XML was supposed to be that generic layer, but you guys have implicitly decided that XML sucks too hard to serve that purpose. I totally agree.
First of all, I'm not saying that property lists themselves are bad. I'm just saying that the old format is more readable and property list XML is useless. The rest of my post focused on preempting arguments that might claim that the use of XML gives you additional functionality for free (which may be valid in some situations, but not this one).
I meant to say that you can't leverage the DTD/Schema stuff to perform validation. (The line above the one you quoted was indented to establish that, but I suppose I probably should have ended it with a colon, huh?) And, like you said, you can do all your validation operationally if you want. Or you could create a declarative system just for property lists. But you can't leverage existing DTD/Schema libraries to handle this for you.
Well, if you don't need editor support, that's great. And it just may be the case that nobody will ever want code-completion-like editor support when editing your configuration files, but I doubt it. You can create a custom editor that understands your custom declarative type system for property lists -- and that's perfectly fine -- but the use of XML achieves nothing here (just decreased readability and a slight performance degredation).I am aware of property lists. The post I responded to was talking about XML in general and not about property lists. My other post explains why property list XML is a stupid idea.
I totally agree that it sucks having to learn many formats, especially when the difference is arbitrary. However, the reason people object to XML is that it's a really bad format.
Haha. I didn't know we looked like that. Wasn't it the pro-XML people that were the rabbid ones? I wonder when the tables turned.
In my defence, I was only responding to a very pro-XML comment. The again, the guy who brought XML up in the first place was a member of "our" camp, I suppose.