Linked by Thom Holwerda on Sat 11th May 2013 21:41 UTC
Windows "Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
Permalink for comment 561766
To read all comments associated with this story, please click here.
RE[20]: Too funny
by satsujinka on Thu 16th May 2013 06:08 UTC in reply to "RE[19]: Too funny"
Member since:

No, you as a programmer would be using the higher level abstraction of the tupple without caring about the mechanics used to implement them. You keep thinking in terms of programs parsing text streams, but with the tupple abstraction you can skip the intermediary text conversions entirely. You only need code to convert the tupple to text at the point where text is the desired form of output like in the shell or a logfile. I'm not sure your understanding this point.

Going back to your interface/class metaphor. I'm not the guy using the interface. I'm the guy writing the interpreter/compiler/VM that dispatches to the correct class on a particular method call from an interface. In which case, I do care how things are implemented, because I want to implement them!

As it stands, there is no hardware notion of a tuple. We just have data streams. So we either have to delimit the data or we have to multiplex the stream. If there are other options then please let me know, but "use higher abstraction" is not a means to implement a system.

If you're not interested in discussing how to implement a relational I/O stream abstraction (which we already both agree would be nice,) I guess there's really nothing else to talk about.

Moving back, my methodology is perfectly sound. I was not trying to show CSV is easier to parse. I was disproving your claim that CSV is particularly hard to parse. The fact that 2 common formats (1 of which you recommended) take more work to parse then CSV, in any general purpose language, is a sound disproof of your claim.

XML does not and cannot provide self-defining metadata. Consider your example of XML providing names. What do metadata do those names provide? What metadata does <contains>...</contains> provide? That something is contained? What if it's a type declaration? (x contains this type) In order to answer the question of what metadata is present, we need some context and if we need a context; then by definition our metadata is not self-defined. This is true of all data formats. Within a context it does make sense to say that some data has a meaning, but outside of it? No.

So back to what I originally said: XML is matched on name and CSV is matched on position. This is how we determine meaning for these two formats. Metadata follows this rule too. In XML we specify metadata with a known name (contains?) and in CSV we specify metadata with a known position (2nd?)

Reply Parent Score: 2