Well... maybe it's not such a bad idea. IBM has been doing pretty well selling other people's chips (Intel), and pushing linux. Who's to say it can't work for Sun?
I mean, how nice would it be to have the kind of massive redundancy and fault tollerance that we're used to getting from Sun (pull a processor out of a running server: no biggy) but with the kind of horse-power / cost ratio we see with x86 on linux? Espescially with a 64 bit (i.e. potentially use more than 4 gigs of ram well) processor?
Who knows... but it's potentially a good combination.
Or just install FreeS/WAN (http://www.freeswan.org) on some piece of junk computer. Maybe even on the same computer that you use as your gateway or router or firewall (or some all of the above).
"Not sure why your comment got modded as flaimbait as I think your response had merit."
Well, how does that one guy's sig go? "It is easier to mod me down than to say something intelligent"? Something like that. I mean, yeah the bit at the bottom about "here's a nickel, buy yourself a real computer"... well, that's an old joke, and that's all it was: a joke. But what the hell.
I use windows, too. As often as linux. Honestly, the reason why I have the luxuory of using linux on my sole desktop is that I have to use windows on my laptop. Therefore, anything I want to do that must be windows, I have to do on there. At work, it's all on the laptop, all day... but doing most of my "work" through SSH or various other windows client-apps onto linux machines doing the real work.
I gotta say, to all of the people who claim to use windows all of the time and never need to reboot: I honestly don't believe you. I use win2k professional every day, and a lot of days, by 5 o'clock it needs a reboot. I'm not saying that it's BSOD'd, but something has memory leaked all over the place (a *real* OS would not let a memory leak outside persist after the program which caused it has terminated), or the desktop has gone to hell, or the sound is flaking out, or some miscellanious thing has gone wrong. It probably only goes BSOD once every couple of weeks, but I never leave it running more than a day or two at a time.
You know when I reboot my linux boxes? When they lose power or when I recompile the kernel. That's about it. Oh, also, I had to turn off my router to install a new NIC... I wanted to route my 802.11b network separately, so that I could force IPSec on that route.
Well, these are home computers, after all. And I didn't want the prompt to show my real name. The psuedo-anonymity of slash-dot, you know. I mean, if you saw that my prompt was:
[brittney_spiers@granite/home/brittney_spiers]$
Then my secret would be out. And nobody wants that.
Well, obviously no source code control software is gonna compensate for developers who can't write good code, use common sense, and follow *simple* process. Granted, requiring complex process of your developers is asking for trouble, but you can't live without simple rules. Some simple rules really require being backed up by the capabilities of the software, though. An example that comes to mind: consistent atomic checkins.
It goes something like this: say you change a function signature. It is your responsibility to grep for all the uses of that function and change them. It is also your responsibility to check in all of those changes atomically. That is: an all-or-none checkin of a group of files all at once. That group is also bound together into the future (the relationship is not severed after checkin).
Another simple point of process that saves your ass is JOB TRACKING. If your source control repository doesn't link into a job tracking system, then I pitty you. I've been there, and it sucks. It took a while for us to work out exactly what was missing and how to get it... but now that we have implemented it, it makes life livable again. The idea with a job tracking system is: assosciate all of your changes with a job. If you want a bleeding edge revision, then sync to the head revision and don't be surprised when stuff breaks. If you want a rough-around-the-edges version to test against, then sync to the highest revision that is entered in the job tracker. Use the various life-cycle statuses in the job tracker to sync to various points. On the whole: Get all files in QA status, or all files in QATESTED status, or CODECHECK status (or however you choose to name these things in your job tracker), or whatever status you want.
In that way, you don't easily break the build, because before you even try to build off of something, you've tracked its code review and its unit testing. Of course, there are always the possibilities for unit testing problemss, but they are usually going to end up being the fault of a developer not following simple processes. In the example I used above where we changed the signature of a function, and updated all of the calls to that function in the same atomic change... you could have had another developer creating a *new* call to that function in their own working copy of the code. You would, of course never catch that, and they might not either... but hopefully whoever is doing code reviews has an eye open to things like function signature changes, and can catch it at that point.
Make it clear to your developers that changes not assosciated with a job will never see the light of day. Every night, review any untracked changes and email the developer, asking them what the hell.
It's true, there is no way to make everything 100% bullet-proof against checking in bad code. Of course, that's why we do things like freeze integration and test before a release.
Well, I wasn't trying to claim that 180 days was a big deal. That wasn't supposed to be bragging. Hell, that's just my desktop. My point was that "days at a time" is laughable compared to _any_ machine running a stable linux kernel.
The best uptime I've gotten to see personally was for a Checkpoint 1 firewall (a little Sun pizza-box running Solaris) at our colo center that was up from the day we moved in until the day we replaced it with redundant PIX's (434 days later, IIRC).
"Re:Give me ten programmers... (Score:2) by dubiousmike (558126) on Thursday February 20, @12:39AM (#5341500) (http://www.borisfx.com/) I have a home computer running XP and a work computer running 2000. Both run for days without a reset."
Well, hot damn! Let's see how long my desktop has been running since last reboot...
Oh, that's right my wife accidentaly kicked out the power plug once last year... Gotta get off of my duff and by a UPS for that guy. I mean, hell, when she kicked out the plug, it was a good 45 seconds of no net for us after she plugged it back in.
Does windows even have an "uptime" command? Or would it just be too damned embarassing for them?
In the words of the nameless Unix-guy from Dilbert: "Here's a nickel. Go buy yourself a real computer."
"for closed source development you should rarely need to edit the same file unless your team is poorly organized or system poorly designed"
Oh, come on. That's such a load. I'll agree that CVS is a big part of the problem, but not because you shouldn't let more than one developer edit the same file at the same time. Rather, simply because CVS sucks.
I hate to admit it, because I love the open source movement, and I know what an important role CVS plays in it, but CVS relly does bite compared to some of the commercial alternatives. I mean, no trackable atomic changes? No means for integration with job tracking? A shitty-beyond-belief branch methodology? Poor tracking of and integration of changes across branches? Crappy permissioning structure?
Where I work we use Perforce, which I absolutely adore. Does not have any of the issues I listed above, works in unix and windows, is command line easy and has a pretty damn good GUI (compare to WinCVS, ack!), is wonderfully scriptable, and is really not that expensive (although I can definitely understand the desire to spend $0).
Anyway, you can't really expect to have a large group of developers both iterating and maintaining a fairly large codebase without ever needing to edit overlapping files... not unless you keep each function/subroutine/method in its own file. Even then, I imagine you'd still run into occasional change resolution issues. The better way to deal with the problem is not to close your eyes and put your hands over your ears; it's to outfit yourself with decent tools capable of dealing with real life. I know that with perforce, and I would imagine with most other half-decent source management systems, simultaneous edits are really not that big of a deal. Unless you've actually edited the same lines in the same file, the user doesn't typicaly have to do a damn thing. And regardless, it is still the fault of the first user to check in a busted file. Again, atomic changes mean that if it compiled for you, and you check it in, then compiles for everyone else.
Hate to sound like a troll here, but so far this whole "Linux on the XBOX" project smells more like a "How can we make trouble for Microsoft" project than a "ooo if only we could do that we could do something really cool!" project.
Well of course that's what it's about. It was the first thought that went through my head when I saw what was in an Xbox and how much it cost. Thought process:
-XBox has expensive hardware -XBox being sold for less than even microsoft could be paying for this -I hate microsoft, would do most anything I can think of to cause them pain -I wonder if, instead of just buying these and throwing them away, I could use them as cheap CPU in a chess-playing beowulf cluster?
CFG's are not implementable as a DFA with a stack. They are actually an NFA with a stack, something that has no direct tie-back to any sort of deterministic automaton. (Whereas, as you noted, NFA's can be expressed as DFA's with an exponential growth in state-space, and Nondeterminstic Turing Machines can be rewritten as TM's with an exponential growth in time-complexity (I'm not saying that they *must* incurr an exponential growth, mind you, just that they can... see P=NP?)... however, a non-deterinstic push-down automaton cannot be rewritten as a deterministic PDA at all.)
Well, it's not like there is necessarily *one* and only one such statement. It's just that the method of the proof (which, to get it straight, simply says that the set of all statements about integers is not possibly both complete and consistent) *demonstrates* the existance of one such statement (it does not limit it to only that statement... in fact, it would be trivial to show that there are an infinite number of such statements, just tack on something trivial).
Also, it is not a "'true' but unprovable statement", per se. It is exactly what the theorem states, not both consistent and complete. More directly: you cannot have any sort of codex of all the statements about integers, and a little flag next to each one saying whether it is a true statement or a false statement. It cannot be both _complete_ (that is, every statement contained), and consistent (that is, that the trueness/falseness flag is correct on every single one). And that is essentially because one of those many statements is (grossly paraphrased):
This statement is false.
Anyway... You're totally right about the parent post, though. WTF?
Re:Friggin less-than's
on
XML and Perl
·
· Score: 1
It is funny. On the other hand, that's such a more suitable task for perl than dealing with xml:
if ($form{Format} eq 'Plain Old Text') {
$form{Comment} =~ s/&/&/g;
$form{Comment} =~ s/</>/g;
$form{Comment} =~ s/>/</g;
}
"Seems like all the best programmers we've hired are also musicians."
Very true. We used to joke here where I work about how we generally didn't hire programmers to program. It basicaly went like "we've got a film-maker (physicist), a poet (physicist), a jazz musician (mathematician), a DJ (english major), and one computer science guy". And that was pretty much true... forget the fact that the two physicists and the mathematician really had been trained in CS, as well, it makes a better story that way.:-D
The point is, though, that outside of a very corporate, dilbertesque world, the quality of the person makes a much bigger difference than his/her specific training. Programming languages and systems can be learned, but intelligence, creativity and passion really can't.
The above includes several places that *should* have had a less-than character. You'd think that posting "Plain Old Text" would properly escape them as <, but I guess you'd be wrong.
Oh, well. You know what I meant.
Re:i hate perl...
on
XML and Perl
·
· Score: 2, Insightful
"I once rewrote a Perl parser in Java and went from 9hrs to 45mins"
Well, shit. I once rewrote a Perl parser in *Perl* and went from 9hrs to 45mins. What the hell kind of flame-bait shit is this!?
It is true that extremely well-written C code can outperform perl code at anything. It is also true that for things that perl is made for (like ripping through tons of text-data), a typical Perl program will *most likely* do it better than a typical C program, simply because it is making use of more optimized underlying algorithms (even though the actual execution structure is slightly more bloated than C... double-dereferencing pointers, compile-time imediately before run-time, etc).... However, Java is just as goddamn interpretted as Perl, if not more so! Perl compiles to *native* byte-code prior to execution, unless you are talking about eval'd strings, whereas Java sits in non-native byte-code that has to be interpretted real-time by the VM. Best case: you have a good just-in-time compiler that pulls Java up to even with Perl (that is, compiled imediately prior to run-time into native byte-code).
Also, Java has all the same disavantages with respect to C... that is more insulation from the *actual* memory (no such thing as a real pointer in either, garbage-collection, etc).
Anyway, bottom-line is this. If what you say is at all true, then you had a shittily-written Perl program. I promise you that I can write just as shitty a program in Java... does that mean that we should trash Java?!?!? Abso-f*cking-lutely not! I'll do you one better, too: I'll write just as shitty and slow of a parser in Java that doesn't even *look* that bad to someone who doesn't understand the subtleties behind such simple abstractions as strings, lists and arrays.
I'm very serious with what I said originaly, I have, in fact, taken a Perl parser (a super-light-weight XML parser, actually) and reduced the parse-time by several orders of magnitude. The idiot who wrote it originaly (myself), went walking through the string or stream looking for 's (with a regexp), at the highest level. It is *terribly* slow to strip leading characters off of a long string in Perl (I'm pretty sure that it copies the whole goddamn string, minus those 10 (or however many) characters on the front). I made a *very* simple change, namely this:
# split on positive lookahead assertion of a ''
# then we just deal individually with blocks of text that all start
# with a ''... should save time
my @xml = split(/(?=)/,' '.$xml);
shift @xml;
And, you'll note that I f*cking commented it (something which people just don't seem to understand when they trash perl). Bang! Many orders of magnitude in speed improvement. Simple.
Well, that's exactly my point. I'm not saying "I don't trust PostgresSQL", I'm just saying that this doesn't really prove anything on its own.
Good for them. Hell, great for them. I'll admit that I really like Oracle, but it's not the one and only universal hammer.
The truth is that it is very difficult to really express what any particular DBMS is good at / bad at/worth in $$$. Too much of the time, the people who actually make purchasing and deployment decisions on database platforms don't really understand the issues. I think that is a large part of why such comparisons aren't very prevelant: that is, the people who could understand them are not the ones who would be using them, so why bother? Just publish FUD, and claim that you either innovate or are Unbreakable.:-)
Because they don't take context or purpose into account at all. There are things that Postress may be better for and things that Oracle certainly shines at. I mean, hell, I love MySQL, too, but I wouldn't want to use it as the backend for _my_ system. Not that the others are hollisticaly "bad", it's just that Oracle is the most appropriate for this situation.
What's a TLD doing with a database? Making ridiculous numbers of extremely lightweight queries, and managing redundancy. That's not necessarily the same thing that everybody wants an "enterprise class" "tested" database to do for "mission critical" tasks.
To this day, the Gemini is about my favorite coaster. There is pretty much never a line, even on the most crowded of days. There is no getting past the fact that it is STILL a good roller coaster... it is not the tallest or fastest, but it is fun, in the good old wooden-coaster style. The racing thing is awesome fun, too. It is silly as hell, I know, but honestly, when you get on that ride, you are part of a team for 2 and a half minutes. You all try to rock your body-weights so it gains that all-important additional hitch on the chain up the first hill.
What a great ride. (Of course... the Raptor is better, but I can ride the Gemini ten times in the time it takes to ride the Raptor:-D)
Well, fair enough. I might have over-stated the amount of time and productivity that perl-specific experience can be worth, but it is still signifigant. Also, when I said that right now I wouldn't consider someone without serious Perl experience, that's a largely a factor of the specific positions I'm looking for right now (senior architects). We've hired a lot of people with zero Perl before and had it work out quite well (though, in some cases the lack of perl has been problematic... one guy who had a lot of varied experience, but was too convinced that the Lisp way was the "right" way and therefore that the Perl way (which is pretty intrinsicaly different from the Lisp way) must be the wrong way... and he kept trying to right Perl like Lisp... ugh).
By the way (it sounds like maybe you were curious), the reason why we conider Perl to be the suitable language is that it was something that had to be written quickly (origingally), and is mostly a matter of glueing lots of different network protocols/data transaction formats together with a database and a web UI. Perl is pretty good glue, and CPAN gives you a lot of the network stuff for free. Boils down to database interface (Perl does pretty well there with DBI), integration into a web-server (can you say Apache/mod_perl? good stuff), and lots and lots and lots of text parsing (nothing better than Perl for that).
No, I'm sorry I have to agree with the guy above (as well as you). It's true that *really* knowing how how to program is more valuable on the whole than being an expert in a particular language... however, on a specific project, and with certain languages (perl is a fairly good example), prior deep experience with the specific language can make a HUGE difference.
[Just so you understand that I'm not talking out of my ass, I've been programming for 20 years, broken down for the large part (with some overlap) as about 9 C/C++, 7 FORTRAN, 5 BASIC , 4 assembly (various) and 4 Perl (plus a bunch of other pedagogical languages like scheme and so on).]
I would consider someone a hell of a lot more valuable if they had a lot of experience with several different programming languages, because, as you said above, they are more likely to understand the fundamental concepts of programming. However, I'm working in a Perl shop right now (and unlike these other posters, I DO make hiring decisions), and at this stage, I wouldn't consider anyone for a senior position who didn't have consierable experience with Perl. There are a lot of reasons, but one of the biggest ones is: 3 months to get up to speed or 6 months? Consider how much they're being paid, and the opporunity cost of 3 more months, and its just not worth it.
Perl is definitely derived from C (as well from shell and various others), but a guy with C and Java and COBOL and whatever else is just NOT gonna be able to run with Perl that quickly, period. Perl is too different in terms of the tools that you actually use (I'm not talking about syntax or silly little idioms and all of the magic variables in Perl). I mean, if you're programming in Perl, and you're not thinking "how would regular expressions and/or hash tables (for example) make this easier?" then you're probably just not doing it right (whatever "it" is). If you're really convinced that isn't how you should be using Perl for this situation, then you probably shouldn't be using Perl anyway. (I love Perl, but it's not the answer to everything).
Ugh, I'm rambling now... anyway, I'd say that what you said is *mostly* true, but almost every language has things about it that separate it and make partiular expertise valuable (in at least some situations). Hire someone to write C/C++ because they know Java, C#, Perl and Basic? But they've never used a pointer!!!! Hire someone to write Java because they've used C/C++, Fortran, and PHP? But are they really thinking about threads from the get-go? Etcetera... I hope you see my point.
Well, actually HIPAA security regulations are not in effect yet. In fact, the security regulations are not even WRITTEN yet. The first *real* application of HIPAA is with the privacy regulations coming in April of this year.
However, the point is well made that when the final HIPAA security regulations do go into effect, they certainly should include provisions about minimal *physical* security measures, as well as the expected network and application security measures.
Slashdot Mirror
Well... maybe it's not such a bad idea. IBM has been doing pretty well selling other people's chips (Intel), and pushing linux. Who's to say it can't work for Sun?
I mean, how nice would it be to have the kind of massive redundancy and fault tollerance that we're used to getting from Sun (pull a processor out of a running server: no biggy) but with the kind of horse-power / cost ratio we see with x86 on linux? Espescially with a 64 bit (i.e. potentially use more than 4 gigs of ram well) processor?
Who knows... but it's potentially a good combination.
Now we just need for linux to get good support for the 64-bit addressable memory (read: more than 4 gigs).
Or just install FreeS/WAN (http://www.freeswan.org) on some piece of junk computer. Maybe even on the same computer that you use as your gateway or router or firewall (or some all of the above).
"Not sure why your comment got modded as flaimbait as I think your response had merit."
Well, how does that one guy's sig go? "It is easier to mod me down than to say something intelligent"? Something like that. I mean, yeah the bit at the bottom about "here's a nickel, buy yourself a real computer"... well, that's an old joke, and that's all it was: a joke. But what the hell.
I use windows, too. As often as linux. Honestly, the reason why I have the luxuory of using linux on my sole desktop is that I have to use windows on my laptop. Therefore, anything I want to do that must be windows, I have to do on there. At work, it's all on the laptop, all day... but doing most of my "work" through SSH or various other windows client-apps onto linux machines doing the real work.
I gotta say, to all of the people who claim to use windows all of the time and never need to reboot: I honestly don't believe you. I use win2k professional every day, and a lot of days, by 5 o'clock it needs a reboot. I'm not saying that it's BSOD'd, but something has memory leaked all over the place (a *real* OS would not let a memory leak outside persist after the program which caused it has terminated), or the desktop has gone to hell, or the sound is flaking out, or some miscellanious thing has gone wrong. It probably only goes BSOD once every couple of weeks, but I never leave it running more than a day or two at a time.
You know when I reboot my linux boxes? When they lose power or when I recompile the kernel. That's about it. Oh, also, I had to turn off my router to install a new NIC... I wanted to route my 802.11b network separately, so that I could force IPSec on that route.
Well, these are home computers, after all. And I didn't want the prompt to show my real name. The psuedo-anonymity of slash-dot, you know. I mean, if you saw that my prompt was:
/home/brittney_spiers]$
[brittney_spiers@granite
Then my secret would be out. And nobody wants that.
Well, obviously no source code control software is gonna compensate for developers who can't write good code, use common sense, and follow *simple* process. Granted, requiring complex process of your developers is asking for trouble, but you can't live without simple rules. Some simple rules really require being backed up by the capabilities of the software, though. An example that comes to mind: consistent atomic checkins.
It goes something like this: say you change a function signature. It is your responsibility to grep for all the uses of that function and change them. It is also your responsibility to check in all of those changes atomically. That is: an all-or-none checkin of a group of files all at once. That group is also bound together into the future (the relationship is not severed after checkin).
Another simple point of process that saves your ass is JOB TRACKING. If your source control repository doesn't link into a job tracking system, then I pitty you. I've been there, and it sucks. It took a while for us to work out exactly what was missing and how to get it... but now that we have implemented it, it makes life livable again. The idea with a job tracking system is: assosciate all of your changes with a job. If you want a bleeding edge revision, then sync to the head revision and don't be surprised when stuff breaks. If you want a rough-around-the-edges version to test against, then sync to the highest revision that is entered in the job tracker. Use the various life-cycle statuses in the job tracker to sync to various points. On the whole: Get all files in QA status, or all files in QATESTED status, or CODECHECK status (or however you choose to name these things in your job tracker), or whatever status you want.
In that way, you don't easily break the build, because before you even try to build off of something, you've tracked its code review and its unit testing. Of course, there are always the possibilities for unit testing problemss, but they are usually going to end up being the fault of a developer not following simple processes. In the example I used above where we changed the signature of a function, and updated all of the calls to that function in the same atomic change... you could have had another developer creating a *new* call to that function in their own working copy of the code. You would, of course never catch that, and they might not either... but hopefully whoever is doing code reviews has an eye open to things like function signature changes, and can catch it at that point.
Make it clear to your developers that changes not assosciated with a job will never see the light of day. Every night, review any untracked changes and email the developer, asking them what the hell.
It's true, there is no way to make everything 100% bullet-proof against checking in bad code. Of course, that's why we do things like freeze integration and test before a release.
Well, I wasn't trying to claim that 180 days was a big deal. That wasn't supposed to be bragging. Hell, that's just my desktop. My point was that "days at a time" is laughable compared to _any_ machine running a stable linux kernel.
The best uptime I've gotten to see personally was for a Checkpoint 1 firewall (a little Sun pizza-box running Solaris) at our colo center that was up from the day we moved in until the day we replaced it with redundant PIX's (434 days later, IIRC).
"Re:Give me ten programmers... (Score:2)
/root]# uptime /root]#
/root]# ssh slate /root]# uptime /root]#
by dubiousmike (558126) on Thursday February 20, @12:39AM (#5341500)
(http://www.borisfx.com/)
I have a home computer running XP and a work computer running 2000. Both run for days without a reset."
Well, hot damn! Let's see how long my desktop has been running since last reboot...
[root@granite
4:46am up 182 days, 5:10, 2 users, load average: 0.00, 0.00, 0.00
[root@granite
Yeah, yeah... I remember those brown-outs late last summer. Oh, I know, what about my router/firewall?
[root@granite
root@slate's password:
[root@slate
12:22am up 164 days, 8:47, 1 user, load average: 0.00, 0.00, 0.00
[root@slate
Oh, that's right my wife accidentaly kicked out the power plug once last year... Gotta get off of my duff and by a UPS for that guy. I mean, hell, when she kicked out the plug, it was a good 45 seconds of no net for us after she plugged it back in.
Does windows even have an "uptime" command? Or would it just be too damned embarassing for them?
In the words of the nameless Unix-guy from Dilbert: "Here's a nickel. Go buy yourself a real computer."
"for closed source development you should rarely need to edit the same file unless your team is poorly organized or system poorly designed"
Oh, come on. That's such a load. I'll agree that CVS is a big part of the problem, but not because you shouldn't let more than one developer edit the same file at the same time. Rather, simply because CVS sucks.
I hate to admit it, because I love the open source movement, and I know what an important role CVS plays in it, but CVS relly does bite compared to some of the commercial alternatives. I mean, no trackable atomic changes? No means for integration with job tracking? A shitty-beyond-belief branch methodology? Poor tracking of and integration of changes across branches? Crappy permissioning structure?
Where I work we use Perforce, which I absolutely adore. Does not have any of the issues I listed above, works in unix and windows, is command line easy and has a pretty damn good GUI (compare to WinCVS, ack!), is wonderfully scriptable, and is really not that expensive (although I can definitely understand the desire to spend $0).
Anyway, you can't really expect to have a large group of developers both iterating and maintaining a fairly large codebase without ever needing to edit overlapping files... not unless you keep each function/subroutine/method in its own file. Even then, I imagine you'd still run into occasional change resolution issues. The better way to deal with the problem is not to close your eyes and put your hands over your ears; it's to outfit yourself with decent tools capable of dealing with real life. I know that with perforce, and I would imagine with most other half-decent source management systems, simultaneous edits are really not that big of a deal. Unless you've actually edited the same lines in the same file, the user doesn't typicaly have to do a damn thing. And regardless, it is still the fault of the first user to check in a busted file. Again, atomic changes mean that if it compiled for you, and you check it in, then compiles for everyone else.
Hate to sound like a troll here, but so far this whole "Linux on the XBOX" project smells more like a "How can we make trouble for Microsoft" project than a "ooo if only we could do that we could do something really cool!" project.
Well of course that's what it's about. It was the first thought that went through my head when I saw what was in an Xbox and how much it cost. Thought process:
-XBox has expensive hardware
-XBox being sold for less than even microsoft could be paying for this
-I hate microsoft, would do most anything I can think of to cause them pain
-I wonder if, instead of just buying these and throwing them away, I could use them as cheap CPU in a chess-playing beowulf cluster?
Yeah, that about sums it up.
"If I want to make a list of lists, and have value semantics, why can't I just say $a[5] = @b?"
It's called:
$a[5] = [@b];
how hard was that? Once again, it's nice to have *control* over value/reference semantics.
Minor note, because I'm being anal, I guess.
CFG's are not implementable as a DFA with a stack. They are actually an NFA with a stack, something that has no direct tie-back to any sort of deterministic automaton. (Whereas, as you noted, NFA's can be expressed as DFA's with an exponential growth in state-space, and Nondeterminstic Turing Machines can be rewritten as TM's with an exponential growth in time-complexity (I'm not saying that they *must* incurr an exponential growth, mind you, just that they can... see P=NP?)... however, a non-deterinstic push-down automaton cannot be rewritten as a deterministic PDA at all.)
Well... Nothing really beats "Evil Petting Zoo", though.
Actually, I don't think that captures the correct semantics of the original statement. For ease of synta, I'll switch to perl:
:-P
$secret = sub { $code_word = 'bush' };
You see the truth is not that the secret *and* the codeword are both bush. Rather, the secret is the assignment of bush to the code word.
Well, it's not like there is necessarily *one* and only one such statement. It's just that the method of the proof (which, to get it straight, simply says that the set of all statements about integers is not possibly both complete and consistent) *demonstrates* the existance of one such statement (it does not limit it to only that statement... in fact, it would be trivial to show that there are an infinite number of such statements, just tack on something trivial).
Also, it is not a "'true' but unprovable statement", per se. It is exactly what the theorem states, not both consistent and complete. More directly: you cannot have any sort of codex of all the statements about integers, and a little flag next to each one saying whether it is a true statement or a false statement. It cannot be both _complete_ (that is, every statement contained), and consistent (that is, that the trueness/falseness flag is correct on every single one). And that is essentially because one of those many statements is (grossly paraphrased):
This statement is false.
Anyway... You're totally right about the parent post, though. WTF?
It is funny. On the other hand, that's such a more suitable task for perl than dealing with xml:
if ($form{Format} eq 'Plain Old Text') {
$form{Comment} =~ s/&/&/g;
$form{Comment} =~ s/</>/g;
$form{Comment} =~ s/>/</g;
}
bing-bang-boom. How hard was that?
"Seems like all the best programmers we've hired are also musicians."
:-D
Very true. We used to joke here where I work about how we generally didn't hire programmers to program. It basicaly went like "we've got a film-maker (physicist), a poet (physicist), a jazz musician (mathematician), a DJ (english major), and one computer science guy". And that was pretty much true... forget the fact that the two physicists and the mathematician really had been trained in CS, as well, it makes a better story that way.
The point is, though, that outside of a very corporate, dilbertesque world, the quality of the person makes a much bigger difference than his/her specific training. Programming languages and systems can be learned, but intelligence, creativity and passion really can't.
The above includes several places that *should* have had a less-than character. You'd think that posting "Plain Old Text" would properly escape them as <, but I guess you'd be wrong.
Oh, well. You know what I meant.
"I once rewrote a Perl parser in Java and went from 9hrs to 45mins"
... However, Java is just as goddamn interpretted as Perl, if not more so! Perl compiles to *native* byte-code prior to execution, unless you are talking about eval'd strings, whereas Java sits in non-native byte-code that has to be interpretted real-time by the VM. Best case: you have a good just-in-time compiler that pulls Java up to even with Perl (that is, compiled imediately prior to run-time into native byte-code).
Well, shit. I once rewrote a Perl parser in *Perl* and went from 9hrs to 45mins. What the hell kind of flame-bait shit is this!?
It is true that extremely well-written C code can outperform perl code at anything. It is also true that for things that perl is made for (like ripping through tons of text-data), a typical Perl program will *most likely* do it better than a typical C program, simply because it is making use of more optimized underlying algorithms (even though the actual execution structure is slightly more bloated than C... double-dereferencing pointers, compile-time imediately before run-time, etc).
Also, Java has all the same disavantages with respect to C... that is more insulation from the *actual* memory (no such thing as a real pointer in either, garbage-collection, etc).
Anyway, bottom-line is this. If what you say is at all true, then you had a shittily-written Perl program. I promise you that I can write just as shitty a program in Java... does that mean that we should trash Java?!?!? Abso-f*cking-lutely not! I'll do you one better, too: I'll write just as shitty and slow of a parser in Java that doesn't even *look* that bad to someone who doesn't understand the subtleties behind such simple abstractions as strings, lists and arrays.
I'm very serious with what I said originaly, I have, in fact, taken a Perl parser (a super-light-weight XML parser, actually) and reduced the parse-time by several orders of magnitude. The idiot who wrote it originaly (myself), went walking through the string or stream looking for 's (with a regexp), at the highest level. It is *terribly* slow to strip leading characters off of a long string in Perl (I'm pretty sure that it copies the whole goddamn string, minus those 10 (or however many) characters on the front). I made a *very* simple change, namely this:
# split on positive lookahead assertion of a ''
# then we just deal individually with blocks of text that all start
# with a ''... should save time
my @xml = split(/(?=)/,' '.$xml);
shift @xml;
And, you'll note that I f*cking commented it (something which people just don't seem to understand when they trash perl). Bang! Many orders of magnitude in speed improvement. Simple.
Anyway, pull your head out of your ass.
Well, that's exactly my point. I'm not saying "I don't trust PostgresSQL", I'm just saying that this doesn't really prove anything on its own.
/worth in $$$. Too much of the time, the people who actually make purchasing and deployment decisions on database platforms don't really understand the issues. I think that is a large part of why such comparisons aren't very prevelant: that is, the people who could understand them are not the ones who would be using them, so why bother? Just publish FUD, and claim that you either innovate or are Unbreakable. :-)
Good for them. Hell, great for them. I'll admit that I really like Oracle, but it's not the one and only universal hammer.
The truth is that it is very difficult to really express what any particular DBMS is good at / bad at
Because they don't take context or purpose into account at all. There are things that Postress may be better for and things that Oracle certainly shines at. I mean, hell, I love MySQL, too, but I wouldn't want to use it as the backend for _my_ system. Not that the others are hollisticaly "bad", it's just that Oracle is the most appropriate for this situation.
What's a TLD doing with a database? Making ridiculous numbers of extremely lightweight queries, and managing redundancy. That's not necessarily the same thing that everybody wants an "enterprise class" "tested" database to do for "mission critical" tasks.
To this day, the Gemini is about my favorite coaster. There is pretty much never a line, even on the most crowded of days. There is no getting past the fact that it is STILL a good roller coaster... it is not the tallest or fastest, but it is fun, in the good old wooden-coaster style. The racing thing is awesome fun, too. It is silly as hell, I know, but honestly, when you get on that ride, you are part of a team for 2 and a half minutes. You all try to rock your body-weights so it gains that all-important additional hitch on the chain up the first hill.
:-D)
What a great ride. (Of course... the Raptor is better, but I can ride the Gemini ten times in the time it takes to ride the Raptor
Well, fair enough. I might have over-stated the amount of time and productivity that perl-specific experience can be worth, but it is still signifigant. Also, when I said that right now I wouldn't consider someone without serious Perl experience, that's a largely a factor of the specific positions I'm looking for right now (senior architects). We've hired a lot of people with zero Perl before and had it work out quite well (though, in some cases the lack of perl has been problematic... one guy who had a lot of varied experience, but was too convinced that the Lisp way was the "right" way and therefore that the Perl way (which is pretty intrinsicaly different from the Lisp way) must be the wrong way... and he kept trying to right Perl like Lisp... ugh).
By the way (it sounds like maybe you were curious), the reason why we conider Perl to be the suitable language is that it was something that had to be written quickly (origingally), and is mostly a matter of glueing lots of different network protocols/data transaction formats together with a database and a web UI. Perl is pretty good glue, and CPAN gives you a lot of the network stuff for free. Boils down to database interface (Perl does pretty well there with DBI), integration into a web-server (can you say Apache/mod_perl? good stuff), and lots and lots and lots of text parsing (nothing better than Perl for that).
No, I'm sorry I have to agree with the guy above (as well as you). It's true that *really* knowing how how to program is more valuable on the whole than being an expert in a particular language... however, on a specific project, and with certain languages (perl is a fairly good example), prior deep experience with the specific language can make a HUGE difference.
[Just so you understand that I'm not talking out of my ass, I've been programming for 20 years, broken down for the large part (with some overlap) as about 9 C/C++, 7 FORTRAN, 5 BASIC , 4 assembly (various) and 4 Perl (plus a bunch of other pedagogical languages like scheme and so on).]
I would consider someone a hell of a lot more valuable if they had a lot of experience with several different programming languages, because, as you said above, they are more likely to understand the fundamental concepts of programming. However, I'm working in a Perl shop right now (and unlike these other posters, I DO make hiring decisions), and at this stage, I wouldn't consider anyone for a senior position who didn't have consierable experience with Perl. There are a lot of reasons, but one of the biggest ones is: 3 months to get up to speed or 6 months? Consider how much they're being paid, and the opporunity cost of 3 more months, and its just not worth it.
Perl is definitely derived from C (as well from shell and various others), but a guy with C and Java and COBOL and whatever else is just NOT gonna be able to run with Perl that quickly, period. Perl is too different in terms of the tools that you actually use (I'm not talking about syntax or silly little idioms and all of the magic variables in Perl). I mean, if you're programming in Perl, and you're not thinking "how would regular expressions and/or hash tables (for example) make this easier?" then you're probably just not doing it right (whatever "it" is). If you're really convinced that isn't how you should be using Perl for this situation, then you probably shouldn't be using Perl anyway. (I love Perl, but it's not the answer to everything).
Ugh, I'm rambling now... anyway, I'd say that what you said is *mostly* true, but almost every language has things about it that separate it and make partiular expertise valuable (in at least some situations). Hire someone to write C/C++ because they know Java, C#, Perl and Basic? But they've never used a pointer!!!! Hire someone to write Java because they've used C/C++, Fortran, and PHP? But are they really thinking about threads from the get-go? Etcetera... I hope you see my point.
Well, actually HIPAA security regulations are not in effect yet. In fact, the security regulations are not even WRITTEN yet. The first *real* application of HIPAA is with the privacy regulations coming in April of this year.
However, the point is well made that when the final HIPAA security regulations do go into effect, they certainly should include provisions about minimal *physical* security measures, as well as the expected network and application security measures.