With respect, it annoys me when I see sound bites taken out of context and used against someone, even if that person is someone whom I'm opposing (and I am opposed to McCain winning, FYI). He was attempting to put Iraq into perspective -- consider the fact that we've been in Japan and Germany for over 60 years -- Korea for almost as long.
I've seen the video and I don't think the sound byte is taken out of context. The subtext of the question he was asked is that Americans are growing weary of the Iraq war, and want to know if our leaders will reach a point where they say "enough is enough," or if the Iraq war is a blank check that we keep fighting until we "win" (whatever that means). John McCain's answer here (as well as other statements) indicate that he considers pulling out "surrender" and will not consider it.
Having troops stationed in peaceful countries is not the same thing. We're not shipping body bags home from South Korea or Japan on a regular basis, and they aren't costing us $2B a week like Iraq is.
That's all well and good, but unless you're parsing extremely large volumes of text, the issues are probably unimportant. If you trigger Perl's worst-case regex performance, it can take over a minute to match a 30 character string. That's what the graph at the top of the referenced article illustrates.
Try it for yourself:
$ time perl -e '$x= "a" x 30; $x =~/(a?){30}a{30}/'
real 3m20.283s user 3m19.583s sys 0m0.086s
Will you run into this worst-case performance? Probably not, as long as you write good regexes. Would it behoove you to understand that yes, Perl's regexes can have serious performance issues even with small amounts of text? Yes.
Re:Good old RubyOnRails
on
Advanced Rails
·
· Score: 2, Informative
My resume says right at the top that I'm not currently looking for work. Still I get a steady flow of emails soliciting me for Rails jobs.
Also, I was a full-time rails developer for nine months.
You haven't even mentioned the number one problem that makes Firefox slow when it's been open for too long: memory allocation costs associated with heap fragmentation.
So you're the guy who shits tabs in random places in source files, because you haven't figured out how to set up your editor to show you the difference. Please stop doing that. Tabs and spaces are different characters, even if the language you're using today treats them the same. If you're a VIM user, please learn to use "list" and "listchars."
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
No idea about DOM, but schema is certainly accessible from XPath/XQuery/XSLT if you're using a schema-aware parser. You can query for types, do casts etc, and the interpreter will bark if you do it wrong, just as any strongly-typed language would have done. Let's take the XML document <gml:coordinates>100, 200</gml:coordinates> (this is real GML). You get to use whatever schema you want, and parse it all with a schema-aware parser. Now write for me an XPath expression that gives you the number "100" as an integer, without using XPath to manually break apart the string "100, 200."
XQuery I'm not familiar with -- maybe this really is possible at that level.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
Note this is a completely separate parser and is completely outside the XML data model, so all your fancy schema validation, xpath, etc. are useless to access data at this level. Er, no. This is exactly what those fancy technologies do for you. Please write for me an XPath expression that gives you the number "100" from the XML fragment <gml:coordinates>100,200</gml:coordinates>, without using XPath to manually break apart the string "100,200."
You can't. Why? Because XPath doesn't have access to the part of your application in which you broke apart the opaque string "100,200" into actual data. Q.E.D.
Why does JSON "know" this? Because it assumes it. That's the critical difference: JSON assumes a basic set of semantics, and shoe-horns everything into it. XML* assumes almost nothing, but requires a (sometimes hefty) set of additional definitions to encode the desired semantics. XML* allows the application to view the data at several levels of increasing abstraction; with JSON, the data is available exactly one way. This is a really fundamental misunderstanding of the difference between JSON and XML. To demonstrate, I will blow your mind by showing that you can quite effortlessly encode XML semantics using JSON if you really want to: ["html",
["head",
["title", "Some Crappy Web Page"],
["script", "alert('Hello, world!')"],
["link" {"rel": "stylesheet", "href": "foo.css"}],
],
["body",
["h1" "My crappy headline"]
] ]
If this was a useful way to encode data, you could use JSON do to this. But it's not, so nobody does.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 2, Interesting
Wow, dude. Did you stop to think that there are many markup languages built on top of XML that can represent such things?
Yes in fact I did. That's what I was referring to when I talked about the "mountains of horribly complex software" on top of XML.
[0.5k of RDF that expresses 100, 200 as integer coordinates]
Simple enough.
Thank you for expressing so succinctly exactly why I am so depressed. How did you XML people come to have such low standards? How can you call "simple enough" a fragment of code that takes 0.5k of text to express a pair of coordinates, and takes 3 hefty specifications worth of software to make any sense of it (XML, XML Namespaces, and RDF)? Do you realize that the comparable JSON is {"coords": {"x": 100, "y": 200}} which can be fully parsed with well under 500 lines of C?
What words did XML seduce you with that you're willing to put up with this kind of abuse? How can you be convinced that this relationship is good for you?
You're right though, it is just a tree of nodes until you parse it. In fact, it's just one long string until you parse it. Imagine that....
Um, no. It's a tree of nodes after you parse it with an XML parser -- that's the problem.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
Only if your XML Parser doesnt support W3C XML Schema Part 2.
you can add layers like validation onto absolutely anything -- it doesn't mean that what you started with was any good.
JSON has a schema specification in the works too if validation is what you really want. But validation is a separate concern from having real data types, and JSON's design illustrates this. Validation is for checking the structure of the data -- putting data types at this level also is a hack.
from what I can tell, you still don't get real data types from even an XML Schema-respecting parser (like an array of two integers) unless the parser supports the "post schema validation infoset," and it's not even clear to me whether you get real data types then.
it should tip you off that you're using the wrong tool for the job when it takes 2 long and complicated specifications, and something called the "post schema validation infoset" to achieve what JSON achieves in one short and simple one.
Seriously, the argument amounts to "a screwdriver is a great tool for hammering in nails, as long as your screwdriver supports the 'heavy piece of metal taped to the end' specification." Sure, you can probably get that to work, but why did you reach for the screwdriver in the first place?
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
Though I agree with you that many people don't understand the difference between marked-up text and data, your xml solution is inappropriate.
Hey, I took the example (the first one, anyway) from a real XML technology! But another big problem with XML is that there isn't one single obvious way to encode this sort of data. What makes my solution objectively inappropriate compared with yours? What makes yours objectively better? Since there is no objectively correct way to map a 2-tuple of integers onto a tree of nodes and elements, people just do whatever comes to mind. And since there's no canonical way to turn a tree of nodes back into a 2-tuple, you're forced to do that yourself at parse time (or rely on your autogenerated code to do so).
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 2, Insightful
What you are describing is the "mountains of horribly complex software on top of XML" that I was referring to. Sure, you can always add one more layer of standards and software to address the deficiencies of what you started with. You could add a validation layer on top of absolutely anything; that doesn't mean that what you started with is any good.
Also, this isn't just a matter of validation. It's a matter of actually being able to access the structure of the data you're trying to encode. OK, so let's say you've written an XML schema rule for gml:coordinates that says "this must contain numbers, then a comma, then numbers." You still have to run a separate parser to pull that information apart at parse time and convert strings to integers, and that data is still not accessible through the DOM or xpath or whatever.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 5, Insightful
I'm so depressed. You represent an entire generation of programmers who can't figure out the difference between marked-up text and data, and why mark-up languages suck so bad for data interchange.
Pop quiz. Here's an excerpt of GML from that page you linked to.
<gml:coordinates>100,200</gml:coordinates>
Do the contents of this node represent:
the text string "100,200"
the number 100200 (with a customary comma for nice formatting)
the number 100.2 (hey, that's the way that the crazy Europeans do it)
a tuple of two numbers: 100 and 200
"Obviously it's two numbers, they're coordinates" you may say. But such things are not "obvious" to an XML parser. If you're an XML parser the answer is (1): it's a simple text string. So to get to the real data you have to parse that text string again to split on a comma, and to turn the two resulting text strings into numbers. Note this is a completely separate parser and is completely outside the XML data model, so all your fancy schema validation, xpath, etc. are useless to access data at this level.
Why all this pain? Because XML simply has no way to say "this is a list of things" or "this is a number."
Sure, you can approximate such things. You could write something like:
But the fact remains that even though you may intuitively understand this to be two coordinates when you look at it (and at least you can select the coordinates individually with xpath in this example, but they're still strings, not numbers) to XML this is still nothing but a tree of nodes.
Did you catch that? A tree of nodes. You're taking a concept which is logically a pair of integers, and encoding it in a format that's representing it in a tree of nodes. Specifically, that tree looks something like this: elementNode name=gml:coordinates \-> textNode, text="\n " * \-> elementNode name=gml:coordinateX
\-> textNode text="100" \-> textNode, text="\n " * \-> elementNode name=gml:coordinateY
\-> textNode, text="200" \-> textNode, text="\n" *
(*: yep, it keeps all that whitespace that you only intended for formatting. XML is a text markup language, so all text anywhere in the document is significant to the parser.)
So let's recap. Using XML, we've taken a structure which is logically just a pair of integers and encoded it as a tree of 7 nodes, three of which are meaningless whitespace that was only put there for formatting, and even after all this XML has no clue that what we're dealing with is a pair of integers.
Now let's try this example in JSON:
{"coordinates": [100, 200]}
JSON knows two things that your fancy shmancy XML parser will never know: that 100 and 200 are numbers, and that they are two elements of an array (which might be more appropriately thought of as a "tuple" in this context). It's smart enough to know that the whitespace is not significant, it doesn't build this complex and meaningless node tree; it just lets you express, directly and succinctly, the data you are trying to encode.
That's because JSON is a data format, and XML is a marked up text format. But we're suffering from the fact that no one realized this ten years ago, and compensated for the parity mismatch by layering mountains of horribly complex software on top of XML instead of just using something that is actually good at data interchange.
Voting by issue would not have made you consider how Bush would react to 9/11 or whether he would lead us into Iraq. "Pre-emptive war based on sketchy intelligence" was not one of his official stances.
All "the issues" can tell you are a few specific instances of how a person will lead, based on the world as it currently stands.
Voting based on character and judgement will help you decide who you want in the driver's seat when the shit hits the fan.
Most difficult were engineers who learned clever tricks to conserving memory in their programming. As Moore's progressed, those skills devalued, then became worthless, and finally became negative in value.
They're not worthless and never will be. There are segments of the industry (say Google) who are constantly pushing the boundaries: they want to process more and more data, and do it faster. Every incremental improvement in efficiency translates into real cost savings. To process and serve more data, you need to be more efficient with your memory. To be faster, you need to be cache-friendly.
Sure, a lot of Google's ingenuity comes from thinking about problems in new ways. But those solutions are always built on the same fundamentals: algorithms and data structures. This stuff just doesn't go out of style. Your best engineers aren't going to be 13 years olds who are untainted by the knowledge of the field, they are going to be experienced people who can understand new ideas in the context of the field. Those people who you've heard about circulating prototype code at Google have stellar academic credentials -- Google is very particular about that in their hiring.
I'm in the position of designing a JIT for my latest project (well not quite yet, but soon), and while I'm considering LLVM, I'm leaning towards DynASM. Why? DynASM is 27kb of source compressed and builds in zero time (it's just a few header files) whereas LLVM is a 4.8MB download and takes something like 15 minutes to build.
I love the goals and scope of the LLVM project, I just wish it were a bit lighter-weight.
Ahh, so what you mean is that massive numbers of native stacks are evil. Well duh.:)
and locks are used internally for queues even for languages with message passing primitives such as Erlang)
As an aside, why is this the case when there is so muchgood research on practical lock-free algorithms? What's with the Erlang guys?
The rules of the performance game are way different when you are dealing with massive parallelism. This is the reason why many concepts from functional languages, such as immutable data structures, are making a comeback.
If you're talking about massive scalability, then not having the option of changing a field in a data structure without allocating and initializing a separate copy first sounds like an expensive proposition. It's bad for memory locality (cache performance), it's bad for heap fragmentation, and it's bad for overall memory footprint. There's a time and a place for immutable data structures, but programming in languages where that's the only option is pretty limiting.
What's wrong with native stacks? Having allocation/deallocation be essentially free for patterns that follow the callgraph of a program is pretty nice, IMO.
and the hint tells the.NET runtime to execute the solution in parallel. No shared memory, no locks, all done for you. That's the way parallelism should work, IMHO
So let me get this straight: the runtime is going to
find one or more other threads to farm this work out to, either by creating new ones or taking them from an existing pool
make the thread(s) runnable, and wait for them to get scheduled by the OS
coordinate the communication between the main thread and the other thread(s) about what part of the solution each thread should work on
...and this is supposed to be faster than a simple for loop with 100 iterations?
Sounds like a losing proposition to me. I don't think this is the kind of parallelism that is going to bring noticeable gains.
I am not a lawyer, but I have had to sign agreements like this and have a keen interest in how far they reach.
Depending on what state you live in, there may be a law on the books along the lines of this:
A provision in an employment agreement which provides that an employee shall assign or offer to assign any of the employee's rights in an invention to the employer does not apply to an invention for which no equipment, supplies, facilities, or trade secret information of the employer was used and which was developed entirely on the employee's own time, unless (a) the invention relates (i) directly to the business of the employer, or (ii) to the employer's actual or demonstrably anticipated research or development, or (b) the invention results from any work performed by the employee for the employer. Any provision which purports to apply to such an invention is to that extent against the public policy of this state and is to that extent void and unenforceable.
This particular law puts things you do on your own time and that are unrelated to the company outside the reach of the company's ownership, and I think this is a fair and important line to draw. Your contract doesn't have any distinction like that, which strikes me as unfair. Your contract says that anything the company finds useful (in its sole discretion) belongs to it, without any qualification.
On the other hand, if you invent something that really is a part of your work and related to the company's business, it seems only right that the company owns it. Your employer is paying you to create and invent things -- they shouldn't have to pay again to use the things that you create!
The six month thing is highly suspect -- how can the company possibly claim to own things you invent after you leave? Definitely talk to a lawyer about this.
My experience is that if you are doing things on the side that are truly unrelated to your work, companies understand. I have actually negotiated with an employer to add a section to my invention assignment agreement specifically recognizing that certain on-the-side projects (which I enumerated) are unrelated to the company business and do not belong to the company.
By the way, the provisions you're talking about fall more under "invention assignment" than "non-compete." Non-competes are usually about preventing you from poaching co-workers or clients, or competing with your company from a business perspective.
Funny, I just spend about two days off and on importing seven years of email (~20k messages, 1.3 GB) into Gmail. I did it by using the POP feature to make Gmail pull all my email from my laptop. It was possible, but not fast (about 200 messages/hour). Still, the IMAP thing could not have come at a more ironic time for me.
Slashdot Mirror
With respect, it annoys me when I see sound bites taken out of context and used against someone, even if that person is someone whom I'm opposing (and I am opposed to McCain winning, FYI). He was attempting to put Iraq into perspective -- consider the fact that we've been in Japan and Germany for over 60 years -- Korea for almost as long.
I've seen the video and I don't think the sound byte is taken out of context. The subtext of the question he was asked is that Americans are growing weary of the Iraq war, and want to know if our leaders will reach a point where they say "enough is enough," or if the Iraq war is a blank check that we keep fighting until we "win" (whatever that means). John McCain's answer here (as well as other statements) indicate that he considers pulling out "surrender" and will not consider it.
Having troops stationed in peaceful countries is not the same thing. We're not shipping body bags home from South Korea or Japan on a regular basis, and they aren't costing us $2B a week like Iraq is.
Try it for yourself:
$ time perl -e '$x= "a" x 30; $x =~
real 3m20.283s
user 3m19.583s
sys 0m0.086s
Will you run into this worst-case performance? Probably not, as long as you write good regexes. Would it behoove you to understand that yes, Perl's regexes can have serious performance issues even with small amounts of text? Yes.
My resume says right at the top that I'm not currently looking for work. Still I get a steady flow of emails soliciting me for Rails jobs.
Also, I was a full-time rails developer for nine months.
You haven't even mentioned the number one problem that makes Firefox slow when it's been open for too long: memory allocation costs associated with heap fragmentation.
So you're the guy who shits tabs in random places in source files, because you haven't figured out how to set up your editor to show you the difference. Please stop doing that. Tabs and spaces are different characters, even if the language you're using today treats them the same. If you're a VIM user, please learn to use "list" and "listchars."
XQuery I'm not familiar with -- maybe this really is possible at that level.
You can't. Why? Because XPath doesn't have access to the part of your application in which you broke apart the opaque string "100,200" into actual data. Q.E.D. Why does JSON "know" this? Because it assumes it. That's the critical difference: JSON assumes a basic set of semantics, and shoe-horns everything into it. XML* assumes almost nothing, but requires a (sometimes hefty) set of additional definitions to encode the desired semantics. XML* allows the application to view the data at several levels of increasing abstraction; with JSON, the data is available exactly one way. This is a really fundamental misunderstanding of the difference between JSON and XML. To demonstrate, I will blow your mind by showing that you can quite effortlessly encode XML semantics using JSON if you really want to:
["html",
["head",
["title", "Some Crappy Web Page"],
["script", "alert('Hello, world!')"],
["link" {"rel": "stylesheet", "href": "foo.css"}],
],
["body",
["h1" "My crappy headline"]
]
]
If this was a useful way to encode data, you could use JSON do to this. But it's not, so nobody does.
Wow, dude. Did you stop to think that there are many markup languages built on top of XML that can represent such things?
Yes in fact I did. That's what I was referring to when I talked about the "mountains of horribly complex software" on top of XML.
[0.5k of RDF that expresses 100, 200 as integer coordinates]
Simple enough.
Thank you for expressing so succinctly exactly why I am so depressed. How did you XML people come to have such low standards? How can you call "simple enough" a fragment of code that takes 0.5k of text to express a pair of coordinates, and takes 3 hefty specifications worth of software to make any sense of it (XML, XML Namespaces, and RDF)? Do you realize that the comparable JSON is {"coords": {"x": 100, "y": 200}} which can be fully parsed with well under 500 lines of C?
What words did XML seduce you with that you're willing to put up with this kind of abuse? How can you be convinced that this relationship is good for you?
You're right though, it is just a tree of nodes until you parse it. In fact, it's just one long string until you parse it. Imagine that....
Um, no. It's a tree of nodes after you parse it with an XML parser -- that's the problem.
- you can add layers like validation onto absolutely anything -- it doesn't mean that what you started with was any good.
- JSON has a schema specification in the works too if validation is what you really want. But validation is a separate concern from having real data types, and JSON's design illustrates this. Validation is for checking the structure of the data -- putting data types at this level also is a hack.
- from what I can tell, you still don't get real data types from even an XML Schema-respecting parser (like an array of two integers) unless the parser supports the "post schema validation infoset," and it's not even clear to me whether you get real data types then.
- it should tip you off that you're using the wrong tool for the job when it takes 2 long and complicated specifications, and something called the "post schema validation infoset" to achieve what JSON achieves in one short and simple one.
Seriously, the argument amounts to "a screwdriver is a great tool for hammering in nails, as long as your screwdriver supports the 'heavy piece of metal taped to the end' specification." Sure, you can probably get that to work, but why did you reach for the screwdriver in the first place?Though I agree with you that many people don't understand the difference between marked-up text and data, your xml solution is inappropriate.
Hey, I took the example (the first one, anyway) from a real XML technology! But another big problem with XML is that there isn't one single obvious way to encode this sort of data. What makes my solution objectively inappropriate compared with yours? What makes yours objectively better? Since there is no objectively correct way to map a 2-tuple of integers onto a tree of nodes and elements, people just do whatever comes to mind. And since there's no canonical way to turn a tree of nodes back into a 2-tuple, you're forced to do that yourself at parse time (or rely on your autogenerated code to do so).
What you are describing is the "mountains of horribly complex software on top of XML" that I was referring to. Sure, you can always add one more layer of standards and software to address the deficiencies of what you started with. You could add a validation layer on top of absolutely anything; that doesn't mean that what you started with is any good.
Also, this isn't just a matter of validation. It's a matter of actually being able to access the structure of the data you're trying to encode. OK, so let's say you've written an XML schema rule for gml:coordinates that says "this must contain numbers, then a comma, then numbers." You still have to run a separate parser to pull that information apart at parse time and convert strings to integers, and that data is still not accessible through the DOM or xpath or whatever.
Pop quiz. Here's an excerpt of GML from that page you linked to.Do the contents of this node represent:
- the text string "100,200"
- the number 100200 (with a customary comma for nice formatting)
- the number 100.2 (hey, that's the way that the crazy Europeans do it)
- a tuple of two numbers: 100 and 200
"Obviously it's two numbers, they're coordinates" you may say. But such things are not "obvious" to an XML parser. If you're an XML parser the answer is (1): it's a simple text string. So to get to the real data you have to parse that text string again to split on a comma, and to turn the two resulting text strings into numbers. Note this is a completely separate parser and is completely outside the XML data model, so all your fancy schema validation, xpath, etc. are useless to access data at this level.Why all this pain? Because XML simply has no way to say "this is a list of things" or "this is a number."
Sure, you can approximate such things. You could write something like:But the fact remains that even though you may intuitively understand this to be two coordinates when you look at it (and at least you can select the coordinates individually with xpath in this example, but they're still strings, not numbers) to XML this is still nothing but a tree of nodes.
Did you catch that? A tree of nodes. You're taking a concept which is logically a pair of integers, and encoding it in a format that's representing it in a tree of nodes. Specifically, that tree looks something like this:
elementNode name=gml:coordinates
\-> textNode, text="\n " *
\-> elementNode name=gml:coordinateX
\-> textNode text="100"
\-> textNode, text="\n " *
\-> elementNode name=gml:coordinateY
\-> textNode, text="200"
\-> textNode, text="\n" *
(*: yep, it keeps all that whitespace that you only intended for formatting. XML is a text markup language, so all text anywhere in the document is significant to the parser.)
So let's recap. Using XML, we've taken a structure which is logically just a pair of integers and encoded it as a tree of 7 nodes, three of which are meaningless whitespace that was only put there for formatting, and even after all this XML has no clue that what we're dealing with is a pair of integers.
Now let's try this example in JSON:JSON knows two things that your fancy shmancy XML parser will never know: that 100 and 200 are numbers, and that they are two elements of an array (which might be more appropriately thought of as a "tuple" in this context). It's smart enough to know that the whitespace is not significant, it doesn't build this complex and meaningless node tree; it just lets you express, directly and succinctly, the data you are trying to encode.
That's because JSON is a data format, and XML is a marked up text format. But we're suffering from the fact that no one realized this ten years ago, and compensated for the parity mismatch by layering mountains of horribly complex software on top of XML instead of just using something that is actually good at data interchange.
I've watched a lot of demos, and my favorite will always be Bakkslide 7: YouTube link, download page for Win32 binary.
Voting by issue would not have made you consider how Bush would react to 9/11 or whether he would lead us into Iraq. "Pre-emptive war based on sketchy intelligence" was not one of his official stances.
All "the issues" can tell you are a few specific instances of how a person will lead, based on the world as it currently stands.
Voting based on character and judgement will help you decide who you want in the driver's seat when the shit hits the fan.
Most difficult were engineers who learned clever tricks to conserving memory in their programming. As Moore's progressed, those skills devalued, then became worthless, and finally became negative in value.
They're not worthless and never will be. There are segments of the industry (say Google) who are constantly pushing the boundaries: they want to process more and more data, and do it faster. Every incremental improvement in efficiency translates into real cost savings. To process and serve more data, you need to be more efficient with your memory. To be faster, you need to be cache-friendly.
Sure, a lot of Google's ingenuity comes from thinking about problems in new ways. But those solutions are always built on the same fundamentals: algorithms and data structures. This stuff just doesn't go out of style. Your best engineers aren't going to be 13 years olds who are untainted by the knowledge of the field, they are going to be experienced people who can understand new ideas in the context of the field. Those people who you've heard about circulating prototype code at Google have stellar academic credentials -- Google is very particular about that in their hiring.
I'm in the position of designing a JIT for my latest project (well not quite yet, but soon), and while I'm considering LLVM, I'm leaning towards DynASM. Why? DynASM is 27kb of source compressed and builds in zero time (it's just a few header files) whereas LLVM is a 4.8MB download and takes something like 15 minutes to build.
I love the goals and scope of the LLVM project, I just wish it were a bit lighter-weight.
So let's take a von Neumann architecture, which has inherent security problems due to it using the same address space for data and code
Oh crap! If only there were a way to partition the address space into data and code parts, and have the processor enforce that! Oh wait, there is.
Hello?? Metroid Prime 3. The controls are so good you forget how you're doing it. You never want to go back to doing FPS any other way.
This one's for you:
Rock Band xkcd
Ahh, so what you mean is that massive numbers of native stacks are evil. Well duh. :)
and locks are used internally for queues even for languages with message passing primitives such as Erlang)
As an aside, why is this the case when there is so much good research on practical lock-free algorithms? What's with the Erlang guys?
The rules of the performance game are way different when you are dealing with massive parallelism. This is the reason why many concepts from functional languages, such as immutable data structures, are making a comeback.
If you're talking about massive scalability, then not having the option of changing a field in a data structure without allocating and initializing a separate copy first sounds like an expensive proposition. It's bad for memory locality (cache performance), it's bad for heap fragmentation, and it's bad for overall memory footprint. There's a time and a place for immutable data structures, but programming in languages where that's the only option is pretty limiting.
2. Native stacks are evil.
What's wrong with native stacks? Having allocation/deallocation be essentially free for patterns that follow the callgraph of a program is pretty nice, IMO.
for (int i = 0; i < 100; i++) {
a[i] = a[i]*a[i];
}
into
Parallel.For(0, 100, delegate(int i) {
a[i] = a[i]*a[i];
});
and the hint tells the
So let me get this straight: the runtime is going to
- find one or more other threads to farm this work out to, either by creating new ones or taking them from an existing pool
- make the thread(s) runnable, and wait for them to get scheduled by the OS
- coordinate the communication between the main thread and the other thread(s) about what part of the solution each thread should work on
...and this is supposed to be faster than a simple for loop with 100 iterations?Sounds like a losing proposition to me. I don't think this is the kind of parallelism that is going to bring noticeable gains.
Depending on what state you live in, there may be a law on the books along the lines of this:This particular law puts things you do on your own time and that are unrelated to the company outside the reach of the company's ownership, and I think this is a fair and important line to draw. Your contract doesn't have any distinction like that, which strikes me as unfair. Your contract says that anything the company finds useful (in its sole discretion) belongs to it, without any qualification.
On the other hand, if you invent something that really is a part of your work and related to the company's business, it seems only right that the company owns it. Your employer is paying you to create and invent things -- they shouldn't have to pay again to use the things that you create!
The six month thing is highly suspect -- how can the company possibly claim to own things you invent after you leave? Definitely talk to a lawyer about this.
My experience is that if you are doing things on the side that are truly unrelated to your work, companies understand. I have actually negotiated with an employer to add a section to my invention assignment agreement specifically recognizing that certain on-the-side projects (which I enumerated) are unrelated to the company business and do not belong to the company.
By the way, the provisions you're talking about fall more under "invention assignment" than "non-compete." Non-competes are usually about preventing you from poaching co-workers or clients, or competing with your company from a business perspective.
DJB makes an unusual and somewhat extreme claim in this paper: he says that the Principle of least privilege is "fundamentally wrong." I thought this was a strange thing for a security person to say, and I wrote a blog entry explaining why I think he's overreacting.
Funny, I just spend about two days off and on importing seven years of email (~20k messages, 1.3 GB) into Gmail. I did it by using the POP feature to make Gmail pull all my email from my laptop. It was possible, but not fast (about 200 messages/hour). Still, the IMAP thing could not have come at a more ironic time for me.