Perl suffers from first mover syndrome. It was drawing upon many established Unix conventions, most of which were unreasonably parsimonious with syntax, though one's definition of "unreasonable" changes in a big hurry coding over a 2400bps dial-up terminal.
PHP's approach was to hit the sweet spot on inception, deal with the short-sightedness later. They managed to bind the design variable "now" to web coding practices circa 1997. I don't think the exorcist exists who can expel that legacy.
I don't actually mind PHP all that much when I'm slumming, and let's not forgot a scalable application or two has been successfully coded in the language, e.g. MediaWiki, which does not have the reputation of being a cesspool of security oversights.
Late 1996, Internet Explorer ships with VBScript enabled. Standards of sanity were pretty subjective for a couple of years as the internet entered the wormhole. At that point in time, PHP would have received a AAA credit rating, no questions asked.
It's not clear to me that if PHP sucks because is was designed too quickly, that Perl6 will also suck because it is being designed too slowly. I missed a step there in the inference chain. Larry Wall has lived through the language fads since Kieth Richards starred in 22 grams.
Lest we forget, the same meme of "after so long, it will suck anyway" was widely applied to Postgres and Firefox and to a certain degree, Debian Sarge.
I'm actually kind of interested to see how a language designed by a war vet turns out.
Meanwhile, I thought I would learn some Lua, but then it turns out that Lua requires a heap, which I can't justify and don't wish to incorporate into my embedded project design.
It's worth calculating the number of gigawatt-hours of electricity is expended on these toy problems. The original goal was to make a political point: we can't assume some of these codes are out of range with present technology. Having made your point, you're just boiling water to arbitrarily make the problem another order of magnitude more expensive to crack.
When did we decide that the major problem facing planet earth was a surplus of electricity we must burn off by any available method?
This has almost 550 vote ups, more than just about anything else on this place, and yet according to launchpad this isn't even supposed to make the hardy release? C'mon guys, 3.3 is a year old, and 3.4 will be in testing shortly after hardy. Some of us like to have a scripted install so we can get ubuntu installed, run our shell script, come back an hour or two later and have everything installed. Yes, it can be downloaded and run from a folder, but we can do that with everything. So if that's the retort people are going to keep kicking back at us why are we even bothering to include apt?
My attempt to run Ganymede from a folder was unsuccessful. Maybe it was the AMD64 thing, I never figured it out, and I don't want to.
Ibex appears to be stuck at 3.2.2. That's Callisto from July 2006. If Jaunty remains stuck at 3.2 in April 2009, I'll begin to seriously wonder about things. Does July 2002 to June 2005 ring any bells with Ubuntu management?
I've read other threads which suggest that Fedora enjoys a small monopoly on the developers who are proficient at packaging Java applications.
[[Had some problems posting from a public terminal. Sorry if my repost ends up becoming a dup.]]
I'm using an older Tek 4-colour lunchbox scope at work.
Setting up triggers is indeed one of the most important tasks. I find the trigger on this scope limited. It has a fifth input for trigger, but lacks the ability to use the trigger channel to *enable* trigger on one of the data channels, which is often what I want to do. Sometimes the events I need to debug arrive in bursts and I can't isolate the middle one.
This scope has a serial data interface which requires the use of the OpenChoice TekVISA capture utility. This stupid thing auto-scans the serial ports at regular intervals, is constantly popping up from the task bar to inform you of its important progress (finding the same instruments it found last time), and generally making it impossible to connect your serial terminals to the COM port you were using moments ago, which are rubber gloved by TekVISA. Apparently to justify its existence it does have the ability to find scopes over the network, which I've never used. Such an annoying piece of crap. I disable it whenever I'm not doing scope captures. It's one of those "what were they thinking" that defined plug&play on early versions of Windows 98. All the elegance of Winnie the Pooh at Daytona beach.
The other thing I dislike about this scope is that there is no button under the cursor wheel to flip between the two cursors; you have to use the four buttons at the side of the screen. That really sucks. A newer version of this scope I used elsewhere had the cursor flip button, and also a network interface, which made data capture a dream relative to TekVISA.
Another thing I don't like is having no apparent time stamp on the main screen for the time of the last trigger event. It has the current time at the bottom, but I haven't found a way yet to determine precisely when it captured the rogue waveform while I was away for lunch.
In many of my microcontroller projects I dedicate an IO pin to signal "now I'm about to configure the peripheral that's really going to screw up". It would sure be nice if I could feed that software defined signal into the external trigger channel to enable auto-trigger on the regular data channels.
I recently adopted Eclipse (Ganymede) for embedded development, along with JIRA for issue tracking and subversion for source control. Previously I've always used distributed version control. At home I use monotone. Here, we have a mixed Windows / Linux team, without much need for distributed SCM at this point in time.
I've been pleasantly shocked at the quality of Tortoise SVN on Windows, and the stability of subclipse under Eclipse. The Mylyn integration where the active JIRA issue is auto-populated into the subclipse commit message is mana from heaven.
We haven't needed to do any heavy merges yet, but in all other respects, subversion has been a perfectly adequate tool. Long term, I expect the distributed designs to prevail, but in the short term, the Windows integration offered by subversion is hard to beat.
I don't recall seeing "irritation" enshrined in the constitution. For someone who claims to have done traffic simulations, it strikes me from your post that you failed to notice much nuance. I suppose you were too consumed with your psychological projections.
On the highway (the kind we have around here with frequent traffic lights), a small amount of breaking early to correct your phase with respect to an upcoming red light often leads to arriving at the light just as the light changes carrying a fair bit of speed.
When I do this, I tend to blow past the irritable driver who didn't like my early coasting, changed lanes, raced up to the light, and came to a dead stop in the lane beside me. If I'm good, I'm right behind the car in front of me as I cruise through the light. The greedy algorithm is not always the most efficient algorithm.
My experience with irritable drivers is that these people tend to be irritable because they are talking on their cell phones, or in some other way diverting their attention, and any driver around them who behaves differently than the 1% of their brain engaged in operating their vehicle expects, they get steamed at the interruption of their other important mind flow. When I drive, I have only one mind flow.
Drivers who aren't on their cell phones often notice that you are slowing down early for a light that just changed red. They have enough brain cells engaged in driving to realize they were only going to get stuck at the light anyway.
Now, personally, I'm not about to change my driving habits so that someone devoting 90% of their brain cycles to dialing their cell phone doesn't have to think about what I'm doing.
The situation where coasting to a red light can screw the driver behind you is the where the driver behind you intends to make a left turn, and has a left turn lane with an advance left turn signal, but is being held back by some guy (me) coasting for the light to change on the straight-through cycle. If I notice the guy behind me signaling for a left turn, and he has a chance to make it, I defer my coasting.
I especially enjoy the situation where the car behind me was too lazy to signal left, I end up coasting normally, and the car misses a left turn they could have made if I had coasted less aggressively. It's an interesting form of magical thinking that we can optimize for global outcomes without bothering to signal our actions to the cars around us.
A situation I've noticed where a lot of people get screwed into waiting an extra traffic-light cycle is advanced turn lanes. For some reason in this town, most people lollygag through the advance left cycle. I tend to take the advance left fairly hard on the car in front of me. I've never found it dangerous. It's not like you're paying attention to anything else. There's only one advance left around here that grinds to a surprising halt because someone decides to turn left again 50 feet after turning left on the advance green. If I look in my rear view, I often see the car behind on the advance left fail to enter the intersection before I've cleared it, having not anticipated the cars in front would haul backside. Two or three cars could fit into that space. The two or three cars that didn't make it all grind to a halt and wait out a full cycle, which is wasteful of fuel in a global metric.
We have one light on the highway leading out of town with a moderately steep grade. It always amazes me: the truck drivers who are really slow always pull into the left lane coming up to this light so they can pass the really, really slow (e.g. cement trucks). 30s later both lanes are cresting the hill at 60kph, in a 80kph speed zone. Probably the really slow truck has saved himself 5s at the expense of every other car on the road, many of whom will end up stuck at that light for another full cycle.
Because I pay attention, I come to a full stop about 1/3 as often as the guy who pays no attention. Even if I'm down to 10kph as the light changes, that avoids the wo
Some secrets are easier to keep than others. It depends less on the context, more on the secret. Of course, you believe every one of those "leaks". Wikipedia is unreliable, whereas leaky secrets in the general environment are irreproachable. Shifting sands of credibility. I suspect you'd have to level up ten tables at Texas Hold'em to achieve your first belt in industrial counter-espionage. Some pretty important secrets have leaked, and some pretty important secrets didn't. Every secret on its own terms.
I just discovered it is possible to drag tabs from Chrome to FF3 by dragging the star at the right side of the Omnibox, rather than dragging the tab as a whole. Parallel browser, here I come.
On my dual monitor Windows box with multiple desktops, one of my biggest problems with Firefox is window proliferation. I end up with too many Firefox windows open on too many desktops. On most desktops, I like to have one Firefox on the left display, another Firefox on the right display, so that I can reference on one side, compose on the other.
My first impression of Chrome is favorable. Middle-click opens up a tab immediately to the right of the current tab, unlike FF3, which loads the new tab at the distal end of the opposite spiral arm (the far end of the tab bar). I submitted negative feedback about this on every FF3 beta release. In Chrome, dragging a tab off the tab bar gets you a new window. Nice.
I've also discovered one can drag FF tabs to Chrome. Also nice. But I can't drag Chrome tabs to FF. Not nice, and almost crippling to my parallel-browser Chrome adoption plan.
I'd love to have Chrome on the left monitor, and FF on my right monitor on most desktops. I could use Chrome to access internal web sites, and FF (with ad-block) to access external sites. The lack of control over ads will limit my use of Chrome for external sites for a long time to come.
I don't like the way that internal DNS CNAMEs are first searched on Google, in all likelihood leaking out the internal CNAMEs over unencrypted http connections. If a name such as "secret" resolves to http://secret.localnetwork/ which instantly redirects to http://secret.localnetwork/double_secret_project_area, which comes back with a working web page, it's extremely untoward my notion of ideal privacy that "secret" was searched on Google before all this happened.
I also noticed that the zoom function on Chrome is not retaining my current scroll position. The older FFs also had this blemish, which made zoom almost unusable in many situations.
Seems solid enough for a new release, but it isn't taking me long to spot the rough edges.
I you care about your reputation, and it turns that the bank is at fault, does the bank take responsibility for the damage they have caused to your reputation if they denied payment from an account that should have been in good standing? It's just the nuclear industry claiming cost parity (or something in the vicinity) to other generation technologies, while not mentioned the legislative liability exemption from a liability that would not have been insurable at any price. Oh yes, after the little banking accident, if you show up five times with all the required paper work, we just put the numbers back where they should have been, no harm done.
The credit agency? Find me one credit agency that reports the number of adverse credit entries reversed in the last month where a bank took full responsibility for the reversal. Evne better: broken down by banking institution.
The process of restoring your credit rating is right out of the movie Brazil. Don't resist too long, your credit rating might never recover.
I'll be pushing my payments, thank you very much, until I'm pushing daisies.
This whole debate would be better centered if Firefox put up the same scary boxes for unencrypted.htaccess as it does for self-signed certs. How could one be worse than the other?
Unless you use a password generator (such as apg on OpenBSD) and have a photographic memory, passwordsafe, and never suffer hang-overs, most people re-use similar password structure even if the careless passwords and careful passwords are significantly different (which I doubt is the norm).
What do you think the entropy is on the average person's bank password after half a dozen samples of their unencrypted throw-away passwords have been sprayed around the internet by a bunch of imperioed BGP routers?
And that's not even counting the occasion where you lose the marble momentarily and discover you've just typed your most uber secure password into a login field the wrong tab, which means it now needs to be burned, but who does?
Passwords passed around the internet in plain text just as tainted as any self-signed SSL cert, and twice as self-inflicted. Brought to you by the same grey beards who engineered open SMTP relays.
Minority Report sucked. The sensitivity on that wall-sized display was set to the level where it required a Shatneresque facial tick to get anything to happen at all. Cruise was doing Swan Lake just to accomplish a simple fade. Just what we all need: a 10,000 pixel wide display with a 20dpi gesture camera.
The reason why 80 columns was chosen was because it was pretty universal - everything displayed in 80 columns.
IIRC Apple ][ was 40 characters wide. TRS-80 was 64 characters wide. Osborne had 52 characters (and a bogus panning mode). There were many terminals and PCs that didn't display 80 character screens. And no end of early display calculators.
More to the point, the human eye finds it increasingly difficult to move from the end of a line to the beginning of the next line in dense print where line lengths exceed 60 to 70 characters.
It seems that half of all web designers who ever lived look at their creations with lorem ipsum filled in for the live text. Those tiny characters make the layout look so nice! Pity you can't actually efficiently read the content when the lorem ipsum loved by graphics designers is replaced by a reason to actually visit the page.
My favorite Firefox function of all is text zoom. Except on those web pages where 120 character lines are etched in stone (font size computed as a percentage of display width).
It depends on how you learned to reason about your code. If you learned to reason algebraically, boolean variables are an asset, not an annoyance. If you fundamentally think about your code as a sequence of events in time, break statements are a mental convenience.
In my case, messing around with boolean often results in finding a more succinct or fundamental expression of the algorithm. No break statement has ever improved my grasp of an algorithm.
My experience with HP have been increasingly disappointing. Recently I contemplated the purchase of an HP network printer / scanner. Most network printers with an integrated scanner implement the scanner as a host-based scanner over USB. The HP unit I found seemed to be the exception. Until I read the data sheet more closely. The network scanner degrades resolution to 200dpi. For full resolution scanning, dust off your host-based USB interface. What I found annoying about this is that the brochure blithely advertised "network scanning" as fully supported.
I have a colleague who swears by HP at the enterprise level, but at this point, I wouldn't buy a consumer level appliance unless I had first exhausted the alternatives.
My stock OpenBSD 4.0 / BIND 9.3.2-P1 name server configuration passes with no modifications on my part. I got deviations from 16,000 to 20,000 across several hosts I tried within my network.
It seems to come with the territory that to write secure code, you have to offend people.
A) I disagree with you. B) I think you're wrong. C) That's broken. D) That's broken, get lost.
If you chose A, you've probably never written a line of secure code.
I've been running the Fedora tree for a couple of years because at the time of my last installation, I wished to play around with the IBM Cell development tools, and Fedora was best supported. Since then I moved a server to Ubuntu and was anticipating moving my desktop as well, which I attempted last weekend.
I was expecting the Ubuntu migration to be relatively pain free, but that was far from reality.
The first disappointment was that dual head did not activate itself automatically. I haven't tried to import my old Xinerama config yet. Pages I've found on the internet talk about xrandr instead, with this annoying 2048x2048 limitation. My screens are one LCD 1680x1050 and 1280x1024. I can't put them side by side without exceeding the 2048 horizontal limit, which will disable compiz effects (should I even care?) One post suggested stacking them vertically, 1050+1024 just barely makes it under the 2048 fence. The post doesn't explain the consequences of arranging my screens this way. Will it affect how my task bar functions? I'm left completely in the dark.
I did this install as a network install. I have a bootp server and prefer to install everything by this mechanism. Many of my machines don't even have CD/DVD players. I built my current desktop when SATA was catching on, but SATA DVD drives were hard to find, and I just flatly refused to pay the "floppy tax" by buying yet another useless PATA device. Instead, I spent the money on rock solid Intel network cards with PXE support.
I added Ubuntu to my netboot server in five minutes, and it fired up the first time, only to fail halfway through. After half an hour of tedious slogging through support forums, I found a link to an updated netboot which doesn't fail. Surprised that this problem could persist in HH for so long. It wasn't released last week.
Since installation, in less than eight hours of use, I've already had three desktop crashes requiring a reboot to cure. The keyboard become unresponsive (not even caps lock) and there are strange effects on screen. Sometimes the mouse continues to move, but does nothing else. I figure it's a rendering glitch. The machine still responds to SSH, so I'm able to SSH in and do an orderly reboot. I tried killing a dozen processes, but gave up without managing to crash the desktop back to the console: every process that looked vaguely gnomish or X-ish.
A surprise about the installer was that it allowed me to proceed with the install with *no* desktop selected. There was no text explaining "if you proceed, all you will have is a command line". There was no text helping me choose *which* desktop to install.
It wasn't hard to install the desktop from the command line in a second pass (I almost prefer it) but I was definitely unimpressed by the amount of guidance offered by the installer.
One feature I love about Ubuntu is that when I type a command command for a package not yet installed, it tells me "you need to install X, Y, or Z". Guidance. What an amazing concept.
My immediate reason for making the jump to Ubuntu last weekend was the desire to set up Eclipse to duplicate my development environment at work. My old Fedora was way behind the curve, so I had 3.4 at work and 3.2 at home.
I managed to install Eclipse on Ubuntu and ended up with... 3.2 again. True to its Debian roots, Ubuntu is a full year behind the times with this important package. There is a bit of frenzy on the forums to get 3.4 packaged since the 3.4 release. Appears they've given up on 3.3 completely. Word is that the Ubuntu team lacks enterprise Java expertise and that if a cutting-edge Eclipse matters to you, you should install... Fedora. Fortunately, my aging Fedora was still kicking around as I tend to do my OS upgrades onto fresh hard drives. I'm back on Fedora today, having not yet bothered to solve my Ubuntu problem with dual head.
During the Eclipse install, I experimented with installing most of the recommended package
One intelligent comment on this thread. We can model that with a Poisson distribution.
What was your tell? Translating "mathematically optimum poker" to "immediate pot odds". Optimum? Which optimum? You mean there's more than one? I fold.
OK, what you say is right, but it applies to two-person, zero-sum games. In multi-player games, no strategy is immune to collusion.
Let's refer to optimum play from the conventional game-theoretic context as the unbeatable strategy. Such a two person, zero-sum game such a strategy exists.
It's not necessarily an easy computation. It's a randomized strategy which can be computed before-hand. The U of A people are better are performing this computation.
Even so, they had to simplify the betting structure to make the problem tractable. This is the reason they chose Limit Hold'em. Fewer betting states, smaller game tree, exponentially faster solution time.
There is no particular challenge to No Limit, if the number of allowable betting states were similarly constricted. I think it would be hard to sufficiently constrict this, because strategy would vary as a function of chip stack for both competitors. Maybe it could be roughly interpolated.
As far as randomized play is concerned, the unbeatable strategy tends to be far more randomized than most humans. One expert who played against the U of A system a while back said that his first session was a nightmare until he learned that he couldn't bluff the computer out. The computer had a tendency to call aggressive betting. It expected highly randomized bids based on its own bidding structure, so didn't make a strong inference of strength when confronted by the behaviour.
What few seem to understand is that the unbeatable solution is entirely unlike poker. The unbeatable solution rarely wins. The unbeatable solution will often draw against strategies with glaring weaknesses. It won't ever be beaten, but it also won't maximize advantage of opponent's weaknesses.
Why not? Because it's impossible to take advantage of the weakness in an opponent without exposing yourself to a counter-measure where you would lose (you must stray from the unbeatable path). When you take advantage of a weak opponent, you do it on faith that the opponent is too dumb to spring the optimal counter-measure to your strategic adaptation.
The theory that U of A employs has far less to say about exploiting the weaknesses of your adversary. To do so requires exposing a weakness in your own strategy. How does the algorithm judge whether the exposed weakness is acceptable? Even poor human players can spot certain kinds of weaknesses quickly. There are other weaknesses an expert might not immediately spot. How does the program know which weaknesses are a risk against which players? It doesn't fall out of game theory, it's a matter of human cognition and psychology, and our model for this is far from complete.
One thing we need to include in this model is the incredible difficulty in explaining to most humans that winning in poker and not losing in poker are entirely different enterprises, with entirely different theoretical foundations. Commander Data has trouble assimilating that fact. 100 trillion brain cells and most of us can't reliably multiply a pair of two digit numbers. If computers had invented humans as part of a BI program (biological intelligence), humans would have been tossed aside as barely having achieved perfect game play at Tic-Tac-Toe. What use is 100 trillion brain cells that can't reliably compute a 15% tip after a heavy lunch? Many computers would like to know.
As computers became better at chess, chess as a human enterprise was somewhat devalued. Few of us wish to put the work into it that the modern theory requires.
I fear the same will soon happen with poker. As the elements of the unbeatable strategy become better known, the relatively inexperienced players can hunker down and not lose much money. They won't be able to win, either, because t
somehow manages to turn out hideously unreadable code For some personal and eccentric value of "hideously unreadable" which you left undocumented because you assume... everyone thinks the same as you do.
I've had people tell me my code was unreadable because I use the C language ?: construct too much.
I'm also prone to write:
bool okF = true;
okF |= first_step();
okF |= second_step();
return okF;
I prefer boolean algebra over clunky if/then, switch/case statements. It's closer to reasoning process that establishes code correctness.
Similarly, I *never* use break/continue to mess up my loop iterators. Again, correctness is a boolean function, not a plate of spaghetti.
My idea of unreadable code is any code with nested break/continue/return statements. Makes the logic perilous to follow or restructure.
But if the coder wants to use a rich operator set to concisely express a mathematical relationship, that deters me not at all.
OTOH, any possible intrusion of integer overflow into a calculation needs at least five lines of comments to explain A) why it can't happen, or B) why it won't matter if it does happen, or C) how to fix it when it breaks.
The main thing I want to see in comments is the programmers line of thought in convincing themself that their code is correct and robust, or some facsimile thereof.
By robust I mean will continue to be correct when edits are made in the near proximity.
Is it more of a male or a female trait to cast judgment that a block of code is unreadable without disclosing the personal criteria on readability?
Okay, I'm going to push you on this one. If the drug makes you smarter with no unpleasant short or long-term side-effects, why on earth would it be a bad idea?
Are you being serious?
I'm sure no harm can come to society or the planet from a bunch of reclusive geeks with a smartness fetish amping their brains.
It's entirely possible 6 billion clever monkeys are already on board a runaway train. Our smartness seems to create new problems as fast as it solves the old ones.
A drug for cluefulness might be interesting. Unfortunately, I've never encountered a questionnaire able to reliably detect cluefulness. Most of our intelligence testing apparatus is designed to exclude cluefulness, lest it contaminate the results. while (!cataclysm) {
++smart;
--clue; }
I hate the way RISC is embraced by many as a pretext to operate their brain in neutral.
Consider the x86 read-modify-write address mode, which few RISC chips incorporate.
Compared to the RISC load, operate, store sequence, this saves you: two instruction fetches, the unnecessary use of a named register, unnecessary read/write transfers to the permanent register file, and transferring the *same* load/store address to the memory order buffer *twice*.
Fixed width RISC instruction sets with large register files and full orthogonality typically have terrible code density. This directly reduces the efficiency of the icache, which in modern chips represents far more transistors than RMW address mode support introduces into the core.
ARM is a good study in this. What did ARM end up doing to address their code density / speed problem? They invented Thumb-2, which sacrifices half the register set to achieve a better balance in time and space.
Some of the original RISC ideas might have been good at the time, but times change.
Excessive orthogonality is simply wasteful. Modern compilers don't have great problems with register coloring to achieve efficient code generation. Yes, someone once had to think very hard to code this. How cruel.
Orthogonality is most beneficial to programmers writing assembly by hand, because people aren't nearly so good as compilers at remapping all the registers in a loop every time one instruction in the loop changes.
An excessively large register file can become a liability at call boundaries and context switches. The x86 addressing modes permit more aggressive use of the L1 dcache as an adjunct to the paltry register file. Otherwise, it would have fallen out of the game long ago.
In some areas, x86 is pure liability: the instruction prefix bytes, too many partial flag register updates, a terrible floating point architecture, and a museum of dead and useless 286 instructions which seemed like a bright idea at the time (I think the PHB interned at Intel that year).
In terms of power efficiency, the x86 instruction encoding and paltry register file can't be redeemed. The magic to make these problems disappear costs a lot in power.
But it's stupid to say that x86 has no advantages over traditional RISC. It has plenty, if you stop to think about it.
Your ivory tower comment is rich. Long ago, Knuth founded the discipline of principled pseudo-random number generation. His is a different style of thinking than the "cookbook" audience expects. Sometimes required for problems of greater subtlety. Each to his own, I guess.
I've never understood criticizing others for setting out with a different purpose in life, especially when that purpose is clearly laid out, as it always was with Knuth. Knuth made positive comments about marching to a different drummer. More people should try it, IMHO.
In fact, I thought this post's me-centrism "what have you done for me lately" was itself decidedly out of fashion, since the recent (re)discovery that preserving the planet is essential to humanity's continued existence.
The goal for TeX was to produce a system that would still produce pixel for pixel identical output many decades later. Another post criticized that TeX is not structured. I don't know what advantage Knuth would have gained from that. The advantage of structured programing is that the program becomes more suitable for adapted toward evolving specifications, which is exactly what Knuth wished to avoid.
For suitability to task, Knuth was primarily concerned with typesetting his own TAOCP, which is a fair representation of manuscripts from the high-end of mathematical typesetting.
Google is now in some respects the antithesis of what Knuth was attempted to achieve with TeX. I go to my personal Google maps not knowing from minute to minute if the UI will continue to work as I last used it. Is that a good direction?
From a modern software engineering perspective, the underlying TeX macro language is a frustrating pile of crap. But I accept the reason, in the same vein as I accept Stroustrup's decision for C++ to remain compatible with C, even though bolting C++ abstractions onto the C style declaration syntax remains an undying source of ugliness and detraction.
In Knuth's case, much of this was driven by his long-ago determination that TeX should function as a one-pass system. It was a practical reality at the time he wrote TeX that it functioned this way given the size of the TAOCP manuscript, and Knuth's personal work style.
Knuth was quite open that he is largely opposed to programming by maintenance, but welcomes re-purposing and adaptation.
Is the grass greener on the other side of the fence? On the other side of the fence, we have expat, Jade and DSSSL, to which few of the same criticisms apply. Panacea? I think not. Nor do I think any less of James Clark for having brought it to fruition.
I don't look to the giants among us to pave the road of convenience. I look to the giants among us to illuminate what is possible. It's when the gold brickers arrive from the private sector that I succumb to ennui. Except when I'm the gold bricker myself. Then I become strangely fascinated with my own reflection in the mirror, as if my every keystroke is a clarion click of eternal significance.
It's a rare day at the office when the significance of my work output surpasses the most boring paragraph in the TAOCP.
"Bernard of Chartres used to say that we are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size."
Then along comes the noble idiot who declares "the view is just as good, and life is more comfortable, standing on this loose pile of shifting rocks".
Oh, isn't it amazing that the integral of x is x^2/2 instead of x^pi. Could it be that the integral of x is geometrically determined as half the area of a square with side x?
I deviated from the profession of mathematics long ago, but as far as I'm concerned, the question of invented/discovered was adequately retired by Kolmogorov-Chaitin complexity theory. For some reason, most mathematicians and most physicists seem determined to ignore this.
The formal system you begin with has an arbitrary beginning: the nature of the universal computer used to measure sequence length. In practice, the arbitrary starting point rarely makes a whiff of difference. The maximum disagreement on sequence length is bounded by the complexity of the program by which one machine is able to simulate the other. Since it is possible to construct universal computers of startlingly low complexity (you could easily write out the rules on the back of a business card with a blunt pencil), this bound tends to be minuscule for most universal machines we might choose to adopt for serious purposes.
I recall reading an article, by Putnam I think, where he talks about two different axiomatic formulations of the integers. Both formalisms agree on all the properties of the integers we regard as essential. However, in one system it is always true that if n < m then the set used to represent n id a subset of the set used to represent m. It the other axiomatic foundation, this is not true.
Some foundation points can introduce some strange discrepancies, but rarely anything we regard as material. This could probably be stated as an theorem in complexity theory. You'd have to put some elbow grease into the project to come up with a universal machine which can't compute pi using a "short" program where short is less than say Ackermann(4,4) and more likely, within a golf score of Ackermann(3,4).
[The inverse Ackermann function] appears in the time complexity of some algorithms, such as the disjoint-set data structure and Chazelle's algorithm for minimum spanning trees.... In fact, alpha(n) is less than 5 for any conceivable input size n, since A(4, 4) is on the order of 2^{2^{10^{19729}}}. "For all practical purposes", alpha(n) can be regarded as being a constant.
Perhaps this is why KC theory is so often ignored. People can't wrap their minds around A(4,4) as an example of an extremely small number. The problem is, the philosophical question of invented/discovered demands this cognitive shift. A(4,4) is *not* a large number on the *philosophical* landscape.
Chaitin's omega, however, is the total perspective vortex of theoretical mathematics.
There seems to be a small number of special constants, such as e and pi, that any universal computer anyone has ever found a use for can obtain from a short program. Within this nucleus, a nanoscopically small filagree in the multidimensional fractal of all possible mathematics, the balance shifts toward "discovered". The further one departs from this minute filigree of felicity and virtue, the more the scale tips toward "invented".
If that sounds like fluff, answer this: what is the shortest number one can copyright?
Due to subitization it has never been possible to copyright the integers 1..4. The copyright on 5 probably expired 50,000 years ago. In modern society, there is evidence that 128-bit numbers remain fair game, though the difficulties of enforcing this are notorious. Clearly, five was discovered, the AACS constant was invented.
Not everyone agrees with Chaitin. This post makes a coherent statement of what he might be presuming:
I wouldn't say C or C++ is losing ground. They both continue to serve well in the niches they established.
Meanwhile, other segments of the pie are expanding, and few of these new applications are coded in C or C++. Does that mean C and C++ are losing ground?
There is no language out there that serves as a better C than C, or a better C++ than C++. The people who carp about C++ reject the C++ agenda, which is not to achieve supreme enlightenment, but to cope with any ugly reality you throw at it, across any scale of implementation.
For those who wish to gaze toward enlightenment, there is always Java. Enlightenment is on the other side of a thick, protective window, but my isn't the view pretty? I've yet to encounter an "enlightened" language that offers a doorway rather than a window seat. I would be first in line if the hatch ever opened.
The problem with C/C++ has long been that the number of programming projects far exceeds the number of people who have the particular aptitudes that C/C++ demand: those of us who don't need (or wish) to be protected from ourselves (or the guy programming next to us).
It's not economically practical to force programmers who don't have that temperament to begin with to fight a losing battle with self-imposed coding invariants. I'm glad these people have other language choices where they can thrive within the scope of their particular gifts. I don't feel my role is diminished by their successes.
For those of us who have gone to the trouble to cultivate hardcore program correctness skills, none of the supposed problems in the design of C or C++ are progress limiting factors, not within the zone of applications that demand a hardcore attitude toward program correctness.
It's the natural order of things that hardcore niches are soon vacated by those unsuited to thrive there, leaving behind a critical core of people who specialize in deep-down nastiness.
For example, it's not just anyone who maintains a root DNS server. I can say with some assurance that the person who does so did not earn his (or her) grey hairs by worrying about whether the implementation language supported automatic GC.
Let's take a metaphor from the security sector. Ten years ago, a perimeter firewall was considered a good security measure. This measure alone eliminated 99% of TCP/IP based remote exploits.
These days, most exploits are tunneled through http, or maybe I'm behind the times, and the true threat is now regarded to be some protocol tunneled within http.
Then some genius comes along and says "in the security sector, TCP/IP defenses are losing ground". Quoi? Actually, no one is out there dismantling their TCP/IP based perimeter firewall. It's continuing to do the same essential job as ever.
It's only the bandwagon that has picked up and moved camp. Yes, garbage collection and deep packet inspection are now all the rage. So it goes.
Why not go around saying that sexual reproduction is all the rage these days? Would that imply we could eliminate all the organisms that reproduce asexually, and the earth's ecology would continue to function? Hardly.
These new languages are soaking up much of the new code burden because these language are freed from having to cope with the nastiness at the extremes (small and large) that C/C++ have already taken care of.
I would almost say that defines a success criteria for a programming language: if it removes enough nastiness from the application space, that the next language that comes along is free to function on a higher plane of convenience. C/C++ have both earned their stripes. Which of these new languages will achieve as much?
Slashdot Mirror
Perl suffers from first mover syndrome. It was drawing upon many established Unix conventions, most of which were unreasonably parsimonious with syntax, though one's definition of "unreasonable" changes in a big hurry coding over a 2400bps dial-up terminal.
PHP's approach was to hit the sweet spot on inception, deal with the short-sightedness later. They managed to bind the design variable "now" to web coding practices circa 1997. I don't think the exorcist exists who can expel that legacy.
I don't actually mind PHP all that much when I'm slumming, and let's not forgot a scalable application or two has been successfully coded in the language, e.g. MediaWiki, which does not have the reputation of being a cesspool of security oversights.
Late 1996, Internet Explorer ships with VBScript enabled. Standards of sanity were pretty subjective for a couple of years as the internet entered the wormhole. At that point in time, PHP would have received a AAA credit rating, no questions asked.
It's not clear to me that if PHP sucks because is was designed too quickly, that Perl6 will also suck because it is being designed too slowly. I missed a step there in the inference chain. Larry Wall has lived through the language fads since Kieth Richards starred in 22 grams.
Lest we forget, the same meme of "after so long, it will suck anyway" was widely applied to Postgres and Firefox and to a certain degree, Debian Sarge.
I'm actually kind of interested to see how a language designed by a war vet turns out.
Meanwhile, I thought I would learn some Lua, but then it turns out that Lua requires a heap, which I can't justify and don't wish to incorporate into my embedded project design.
It's worth calculating the number of gigawatt-hours of electricity is expended on these toy problems. The original goal was to make a political point: we can't assume some of these codes are out of range with present technology. Having made your point, you're just boiling water to arbitrarily make the problem another order of magnitude more expensive to crack.
When did we decide that the major problem facing planet earth was a surplus of electricity we must burn off by any available method?
I wish Ubuntu would get their act together on Eclipse.
From http://brainstorm.ubuntu.com/idea/1265/
My attempt to run Ganymede from a folder was unsuccessful. Maybe it was the AMD64 thing, I never figured it out, and I don't want to.
Ibex appears to be stuck at 3.2.2. That's Callisto from July 2006. If Jaunty remains stuck at 3.2 in April 2009, I'll begin to seriously wonder about things. Does July 2002 to June 2005 ring any bells with Ubuntu management?
I've read other threads which suggest that Fedora enjoys a small monopoly on the developers who are proficient at packaging Java applications.
[[Had some problems posting from a public terminal. Sorry if my repost ends up becoming a dup.]]
I'm using an older Tek 4-colour lunchbox scope at work.
Setting up triggers is indeed one of the most important tasks. I find the trigger on this scope limited. It has a fifth input for trigger, but lacks the ability to use the trigger channel to *enable* trigger on one of the data channels, which is often what I want to do. Sometimes the events I need to debug arrive in bursts and I can't isolate the middle one.
This scope has a serial data interface which requires the use of the OpenChoice TekVISA capture utility. This stupid thing auto-scans the serial ports at regular intervals, is constantly popping up from the task bar to inform you of its important progress (finding the same instruments it found last time), and generally making it impossible to connect your serial terminals to the COM port you were using moments ago, which are rubber gloved by TekVISA. Apparently to justify its existence it does have the ability to find scopes over the network, which I've never used. Such an annoying piece of crap. I disable it whenever I'm not doing scope captures. It's one of those "what were they thinking" that defined plug&play on early versions of Windows 98. All the elegance of Winnie the Pooh at Daytona beach.
The other thing I dislike about this scope is that there is no button under the cursor wheel to flip between the two cursors; you have to use the four buttons at the side of the screen. That really sucks. A newer version of this scope I used elsewhere had the cursor flip button, and also a network interface, which made data capture a dream relative to TekVISA.
Another thing I don't like is having no apparent time stamp on the main screen for the time of the last trigger event. It has the current time at the bottom, but I haven't found a way yet to determine precisely when it captured the rogue waveform while I was away for lunch.
In many of my microcontroller projects I dedicate an IO pin to signal "now I'm about to configure the peripheral that's really going to screw up". It would sure be nice if I could feed that software defined signal into the external trigger channel to enable auto-trigger on the regular data channels.
I recently adopted Eclipse (Ganymede) for embedded development, along with JIRA for issue tracking and subversion for source control. Previously I've always used distributed version control. At home I use monotone. Here, we have a mixed Windows / Linux team, without much need for distributed SCM at this point in time.
I've been pleasantly shocked at the quality of Tortoise SVN on Windows, and the stability of subclipse under Eclipse. The Mylyn integration where the active JIRA issue is auto-populated into the subclipse commit message is mana from heaven.
We haven't needed to do any heavy merges yet, but in all other respects, subversion has been a perfectly adequate tool. Long term, I expect the distributed designs to prevail, but in the short term, the Windows integration offered by subversion is hard to beat.
I don't recall seeing "irritation" enshrined in the constitution. For someone who claims to have done traffic simulations, it strikes me from your post that you failed to notice much nuance. I suppose you were too consumed with your psychological projections.
On the highway (the kind we have around here with frequent traffic lights), a small amount of breaking early to correct your phase with respect to an upcoming red light often leads to arriving at the light just as the light changes carrying a fair bit of speed.
When I do this, I tend to blow past the irritable driver who didn't like my early coasting, changed lanes, raced up to the light, and came to a dead stop in the lane beside me. If I'm good, I'm right behind the car in front of me as I cruise through the light. The greedy algorithm is not always the most efficient algorithm.
My experience with irritable drivers is that these people tend to be irritable because they are talking on their cell phones, or in some other way diverting their attention, and any driver around them who behaves differently than the 1% of their brain engaged in operating their vehicle expects, they get steamed at the interruption of their other important mind flow. When I drive, I have only one mind flow.
Drivers who aren't on their cell phones often notice that you are slowing down early for a light that just changed red. They have enough brain cells engaged in driving to realize they were only going to get stuck at the light anyway.
Now, personally, I'm not about to change my driving habits so that someone devoting 90% of their brain cycles to dialing their cell phone doesn't have to think about what I'm doing.
The situation where coasting to a red light can screw the driver behind you is the where the driver behind you intends to make a left turn, and has a left turn lane with an advance left turn signal, but is being held back by some guy (me) coasting for the light to change on the straight-through cycle. If I notice the guy behind me signaling for a left turn, and he has a chance to make it, I defer my coasting.
I especially enjoy the situation where the car behind me was too lazy to signal left, I end up coasting normally, and the car misses a left turn they could have made if I had coasted less aggressively. It's an interesting form of magical thinking that we can optimize for global outcomes without bothering to signal our actions to the cars around us.
A situation I've noticed where a lot of people get screwed into waiting an extra traffic-light cycle is advanced turn lanes. For some reason in this town, most people lollygag through the advance left cycle. I tend to take the advance left fairly hard on the car in front of me. I've never found it dangerous. It's not like you're paying attention to anything else. There's only one advance left around here that grinds to a surprising halt because someone decides to turn left again 50 feet after turning left on the advance green. If I look in my rear view, I often see the car behind on the advance left fail to enter the intersection before I've cleared it, having not anticipated the cars in front would haul backside. Two or three cars could fit into that space. The two or three cars that didn't make it all grind to a halt and wait out a full cycle, which is wasteful of fuel in a global metric.
We have one light on the highway leading out of town with a moderately steep grade. It always amazes me: the truck drivers who are really slow always pull into the left lane coming up to this light so they can pass the really, really slow (e.g. cement trucks). 30s later both lanes are cresting the hill at 60kph, in a 80kph speed zone. Probably the really slow truck has saved himself 5s at the expense of every other car on the road, many of whom will end up stuck at that light for another full cycle.
Because I pay attention, I come to a full stop about 1/3 as often as the guy who pays no attention. Even if I'm down to 10kph as the light changes, that avoids the wo
Some secrets are easier to keep than others. It depends less on the context, more on the secret. Of course, you believe every one of those "leaks". Wikipedia is unreliable, whereas leaky secrets in the general environment are irreproachable. Shifting sands of credibility. I suspect you'd have to level up ten tables at Texas Hold'em to achieve your first belt in industrial counter-espionage. Some pretty important secrets have leaked, and some pretty important secrets didn't. Every secret on its own terms.
I just discovered it is possible to drag tabs from Chrome to FF3 by dragging the star at the right side of the Omnibox, rather than dragging the tab as a whole. Parallel browser, here I come.
On my dual monitor Windows box with multiple desktops, one of my biggest problems with Firefox is window proliferation. I end up with too many Firefox windows open on too many desktops. On most desktops, I like to have one Firefox on the left display, another Firefox on the right display, so that I can reference on one side, compose on the other.
My first impression of Chrome is favorable. Middle-click opens up a tab immediately to the right of the current tab, unlike FF3, which loads the new tab at the distal end of the opposite spiral arm (the far end of the tab bar). I submitted negative feedback about this on every FF3 beta release. In Chrome, dragging a tab off the tab bar gets you a new window. Nice.
I've also discovered one can drag FF tabs to Chrome. Also nice. But I can't drag Chrome tabs to FF. Not nice, and almost crippling to my parallel-browser Chrome adoption plan.
I'd love to have Chrome on the left monitor, and FF on my right monitor on most desktops. I could use Chrome to access internal web sites, and FF (with ad-block) to access external sites. The lack of control over ads will limit my use of Chrome for external sites for a long time to come.
I don't like the way that internal DNS CNAMEs are first searched on Google, in all likelihood leaking out the internal CNAMEs over unencrypted http connections. If a name such as "secret" resolves to http://secret.localnetwork/ which instantly redirects to http://secret.localnetwork/double_secret_project_area, which comes back with a working web page, it's extremely untoward my notion of ideal privacy that "secret" was searched on Google before all this happened.
I also noticed that the zoom function on Chrome is not retaining my current scroll position. The older FFs also had this blemish, which made zoom almost unusable in many situations.
Seems solid enough for a new release, but it isn't taking me long to spot the rough edges.
I you care about your reputation, and it turns that the bank is at fault, does the bank take responsibility for the damage they have caused to your reputation if they denied payment from an account that should have been in good standing? It's just the nuclear industry claiming cost parity (or something in the vicinity) to other generation technologies, while not mentioned the legislative liability exemption from a liability that would not have been insurable at any price. Oh yes, after the little banking accident, if you show up five times with all the required paper work, we just put the numbers back where they should have been, no harm done.
The credit agency? Find me one credit agency that reports the number of adverse credit entries reversed in the last month where a bank took full responsibility for the reversal. Evne better: broken down by banking institution.
The process of restoring your credit rating is right out of the movie Brazil. Don't resist too long, your credit rating might never recover.
I'll be pushing my payments, thank you very much, until I'm pushing daisies.
This whole debate would be better centered if Firefox put up the same scary boxes for unencrypted .htaccess as it does for self-signed certs. How could one be worse than the other?
Unless you use a password generator (such as apg on OpenBSD) and have a photographic memory, passwordsafe, and never suffer hang-overs, most people re-use similar password structure even if the careless passwords and careful passwords are significantly different (which I doubt is the norm).
What do you think the entropy is on the average person's bank password after half a dozen samples of their unencrypted throw-away passwords have been sprayed around the internet by a bunch of imperioed BGP routers?
And that's not even counting the occasion where you lose the marble momentarily and discover you've just typed your most uber secure password into a login field the wrong tab, which means it now needs to be burned, but who does?
Passwords passed around the internet in plain text just as tainted as any self-signed SSL cert, and twice as self-inflicted. Brought to you by the same grey beards who engineered open SMTP relays.
Minority Report sucked. The sensitivity on that wall-sized display was set to the level where it required a Shatneresque facial tick to get anything to happen at all. Cruise was doing Swan Lake just to accomplish a simple fade. Just what we all need: a 10,000 pixel wide display with a 20dpi gesture camera.
The reason why 80 columns was chosen was because it was pretty universal - everything displayed in 80 columns.
IIRC Apple ][ was 40 characters wide. TRS-80 was 64 characters wide. Osborne had 52 characters (and a bogus panning mode). There were many terminals and PCs that didn't display 80 character screens. And no end of early display calculators.
More to the point, the human eye finds it increasingly difficult to move from the end of a line to the beginning of the next line in dense print where line lengths exceed 60 to 70 characters.
It seems that half of all web designers who ever lived look at their creations with lorem ipsum filled in for the live text. Those tiny characters make the layout look so nice! Pity you can't actually efficiently read the content when the lorem ipsum loved by graphics designers is replaced by a reason to actually visit the page.
My favorite Firefox function of all is text zoom. Except on those web pages where 120 character lines are etched in stone (font size computed as a percentage of display width).
It depends on how you learned to reason about your code. If you learned to reason algebraically, boolean variables are an asset, not an annoyance. If you fundamentally think about your code as a sequence of events in time, break statements are a mental convenience.
In my case, messing around with boolean often results in finding a more succinct or fundamental expression of the algorithm. No break statement has ever improved my grasp of an algorithm.
My experience with HP have been increasingly disappointing. Recently I contemplated the purchase of an HP network printer / scanner. Most network printers with an integrated scanner implement the scanner as a host-based scanner over USB. The HP unit I found seemed to be the exception. Until I read the data sheet more closely. The network scanner degrades resolution to 200dpi. For full resolution scanning, dust off your host-based USB interface. What I found annoying about this is that the brochure blithely advertised "network scanning" as fully supported.
I have a colleague who swears by HP at the enterprise level, but at this point, I wouldn't buy a consumer level appliance unless I had first exhausted the alternatives.
My stock OpenBSD 4.0 / BIND 9.3.2-P1 name server configuration passes with no modifications on my part. I got deviations from 16,000 to 20,000 across several hosts I tried within my network.
It seems to come with the territory that to write secure code, you have to offend people.
A) I disagree with you.
B) I think you're wrong.
C) That's broken.
D) That's broken, get lost.
If you chose A, you've probably never written a line of secure code.
I've been running the Fedora tree for a couple of years because at the time of my last installation, I wished to play around with the IBM Cell development tools, and Fedora was best supported. Since then I moved a server to Ubuntu and was anticipating moving my desktop as well, which I attempted last weekend.
I was expecting the Ubuntu migration to be relatively pain free, but that was far from reality.
The first disappointment was that dual head did not activate itself automatically. I haven't tried to import my old Xinerama config yet. Pages I've found on the internet talk about xrandr instead, with this annoying 2048x2048 limitation. My screens are one LCD 1680x1050 and 1280x1024. I can't put them side by side without exceeding the 2048 horizontal limit, which will disable compiz effects (should I even care?) One post suggested stacking them vertically, 1050+1024 just barely makes it under the 2048 fence. The post doesn't explain the consequences of arranging my screens this way. Will it affect how my task bar functions? I'm left completely in the dark.
I did this install as a network install. I have a bootp server and prefer to install everything by this mechanism. Many of my machines don't even have CD/DVD players. I built my current desktop when SATA was catching on, but SATA DVD drives were hard to find, and I just flatly refused to pay the "floppy tax" by buying yet another useless PATA device. Instead, I spent the money on rock solid Intel network cards with PXE support.
I added Ubuntu to my netboot server in five minutes, and it fired up the first time, only to fail halfway through. After half an hour of tedious slogging through support forums, I found a link to an updated netboot which doesn't fail. Surprised that this problem could persist in HH for so long. It wasn't released last week.
Since installation, in less than eight hours of use, I've already had three desktop crashes requiring a reboot to cure. The keyboard become unresponsive (not even caps lock) and there are strange effects on screen. Sometimes the mouse continues to move, but does nothing else. I figure it's a rendering glitch. The machine still responds to SSH, so I'm able to SSH in and do an orderly reboot. I tried killing a dozen processes, but gave up without managing to crash the desktop back to the console: every process that looked vaguely gnomish or X-ish.
A surprise about the installer was that it allowed me to proceed with the install with *no* desktop selected. There was no text explaining "if you proceed, all you will have is a command line". There was no text helping me choose *which* desktop to install.
It wasn't hard to install the desktop from the command line in a second pass (I almost prefer it) but I was definitely unimpressed by the amount of guidance offered by the installer.
One feature I love about Ubuntu is that when I type a command command for a package not yet installed, it tells me "you need to install X, Y, or Z". Guidance. What an amazing concept.
My immediate reason for making the jump to Ubuntu last weekend was the desire to set up Eclipse to duplicate my development environment at work. My old Fedora was way behind the curve, so I had 3.4 at work and 3.2 at home.
I managed to install Eclipse on Ubuntu and ended up with ... 3.2 again. True to its Debian roots, Ubuntu is a full year behind the times with this important package. There is a bit of frenzy on the forums to get 3.4 packaged since the 3.4 release. Appears they've given up on 3.3 completely. Word is that the Ubuntu team lacks enterprise Java expertise and that if a cutting-edge Eclipse matters to you, you should install ... Fedora. Fortunately, my aging Fedora was still kicking around as I tend to do my OS upgrades onto fresh hard drives. I'm back on Fedora today, having not yet bothered to solve my Ubuntu problem with dual head.
During the Eclipse install, I experimented with installing most of the recommended package
One intelligent comment on this thread. We can model that with a Poisson distribution.
What was your tell? Translating "mathematically optimum poker" to "immediate pot odds". Optimum? Which optimum? You mean there's more than one? I fold.
OK, what you say is right, but it applies to two-person, zero-sum games. In multi-player games, no strategy is immune to collusion.
Let's refer to optimum play from the conventional game-theoretic context as the unbeatable strategy. Such a two person, zero-sum game such a strategy exists.
It's not necessarily an easy computation. It's a randomized strategy which can be computed before-hand. The U of A people are better are performing this computation.
Even so, they had to simplify the betting structure to make the problem tractable. This is the reason they chose Limit Hold'em. Fewer betting states, smaller game tree, exponentially faster solution time.
There is no particular challenge to No Limit, if the number of allowable betting states were similarly constricted. I think it would be hard to sufficiently constrict this, because strategy would vary as a function of chip stack for both competitors. Maybe it could be roughly interpolated.
As far as randomized play is concerned, the unbeatable strategy tends to be far more randomized than most humans. One expert who played against the U of A system a while back said that his first session was a nightmare until he learned that he couldn't bluff the computer out. The computer had a tendency to call aggressive betting. It expected highly randomized bids based on its own bidding structure, so didn't make a strong inference of strength when confronted by the behaviour.
What few seem to understand is that the unbeatable solution is entirely unlike poker. The unbeatable solution rarely wins. The unbeatable solution will often draw against strategies with glaring weaknesses. It won't ever be beaten, but it also won't maximize advantage of opponent's weaknesses.
Why not? Because it's impossible to take advantage of the weakness in an opponent without exposing yourself to a counter-measure where you would lose (you must stray from the unbeatable path). When you take advantage of a weak opponent, you do it on faith that the opponent is too dumb to spring the optimal counter-measure to your strategic adaptation.
The theory that U of A employs has far less to say about exploiting the weaknesses of your adversary. To do so requires exposing a weakness in your own strategy. How does the algorithm judge whether the exposed weakness is acceptable? Even poor human players can spot certain kinds of weaknesses quickly. There are other weaknesses an expert might not immediately spot. How does the program know which weaknesses are a risk against which players? It doesn't fall out of game theory, it's a matter of human cognition and psychology, and our model for this is far from complete.
One thing we need to include in this model is the incredible difficulty in explaining to most humans that winning in poker and not losing in poker are entirely different enterprises, with entirely different theoretical foundations. Commander Data has trouble assimilating that fact. 100 trillion brain cells and most of us can't reliably multiply a pair of two digit numbers. If computers had invented humans as part of a BI program (biological intelligence), humans would have been tossed aside as barely having achieved perfect game play at Tic-Tac-Toe. What use is 100 trillion brain cells that can't reliably compute a 15% tip after a heavy lunch? Many computers would like to know.
As computers became better at chess, chess as a human enterprise was somewhat devalued. Few of us wish to put the work into it that the modern theory requires.
I fear the same will soon happen with poker. As the elements of the unbeatable strategy become better known, the relatively inexperienced players can hunker down and not lose much money. They won't be able to win, either, because t
Actually, if I was writing code instead of words, that would have been the only thing I was worried about.
ok &= statement;
error |= statement;
Glass half full, glass half empty.
I've had people tell me my code was unreadable because I use the C language ?: construct too much.
I'm also prone to write:
bool okF = true;
okF |= first_step();
okF |= second_step();
return okF;
I prefer boolean algebra over clunky if/then, switch/case statements. It's closer to reasoning process that establishes code correctness.
Similarly, I *never* use break/continue to mess up my loop iterators. Again, correctness is a boolean function, not a plate of spaghetti.
My idea of unreadable code is any code with nested break/continue/return statements. Makes the logic perilous to follow or restructure.
But if the coder wants to use a rich operator set to concisely express a mathematical relationship, that deters me not at all.
OTOH, any possible intrusion of integer overflow into a calculation needs at least five lines of comments to explain A) why it can't happen, or B) why it won't matter if it does happen, or C) how to fix it when it breaks.
The main thing I want to see in comments is the programmers line of thought in convincing themself that their code is correct and robust, or some facsimile thereof.
By robust I mean will continue to be correct when edits are made in the near proximity.
Is it more of a male or a female trait to cast judgment that a block of code is unreadable without disclosing the personal criteria on readability?
Are you being serious?
I'm sure no harm can come to society or the planet from a bunch of reclusive geeks with a smartness fetish amping their brains.
It's entirely possible 6 billion clever monkeys are already on board a runaway train. Our smartness seems to create new problems as fast as it solves the old ones.
A drug for cluefulness might be interesting. Unfortunately, I've never encountered a questionnaire able to reliably detect cluefulness. Most of our intelligence testing apparatus is designed to exclude cluefulness, lest it contaminate the results.
while (!cataclysm) {
++smart;
--clue;
}
What could possibly go wrong?
I hate the way RISC is embraced by many as a pretext to operate their brain in neutral.
Consider the x86 read-modify-write address mode, which few RISC chips incorporate.
Compared to the RISC load, operate, store sequence, this saves you: two instruction fetches, the unnecessary use of a named register, unnecessary read/write transfers to the permanent register file, and transferring the *same* load/store address to the memory order buffer *twice*.
Fixed width RISC instruction sets with large register files and full orthogonality typically have terrible code density. This directly reduces the efficiency of the icache, which in modern chips represents far more transistors than RMW address mode support introduces into the core.
ARM is a good study in this. What did ARM end up doing to address their code density / speed problem? They invented Thumb-2, which sacrifices half the register set to achieve a better balance in time and space.
http://www.arm.com/products/CPUs/archi-thumb2.html
Some of the original RISC ideas might have been good at the time, but times change.
Excessive orthogonality is simply wasteful. Modern compilers don't have great problems with register coloring to achieve efficient code generation. Yes, someone once had to think very hard to code this. How cruel.
Orthogonality is most beneficial to programmers writing assembly by hand, because people aren't nearly so good as compilers at remapping all the registers in a loop every time one instruction in the loop changes.
An excessively large register file can become a liability at call boundaries and context switches. The x86 addressing modes permit more aggressive use of the L1 dcache as an adjunct to the paltry register file. Otherwise, it would have fallen out of the game long ago.
In some areas, x86 is pure liability: the instruction prefix bytes, too many partial flag register updates, a terrible floating point architecture, and a museum of dead and useless 286 instructions which seemed like a bright idea at the time (I think the PHB interned at Intel that year).
In terms of power efficiency, the x86 instruction encoding and paltry register file can't be redeemed. The magic to make these problems disappear costs a lot in power.
But it's stupid to say that x86 has no advantages over traditional RISC. It has plenty, if you stop to think about it.
Your ivory tower comment is rich. Long ago, Knuth founded the discipline of principled pseudo-random number generation. His is a different style of thinking than the "cookbook" audience expects. Sometimes required for problems of greater subtlety. Each to his own, I guess.
I've never understood criticizing others for setting out with a different purpose in life, especially when that purpose is clearly laid out, as it always was with Knuth. Knuth made positive comments about marching to a different drummer. More people should try it, IMHO.
In fact, I thought this post's me-centrism "what have you done for me lately" was itself decidedly out of fashion, since the recent (re)discovery that preserving the planet is essential to humanity's continued existence.
The goal for TeX was to produce a system that would still produce pixel for pixel identical output many decades later. Another post criticized that TeX is not structured. I don't know what advantage Knuth would have gained from that. The advantage of structured programing is that the program becomes more suitable for adapted toward evolving specifications, which is exactly what Knuth wished to avoid.
For suitability to task, Knuth was primarily concerned with typesetting his own TAOCP, which is a fair representation of manuscripts from the high-end of mathematical typesetting.
Google is now in some respects the antithesis of what Knuth was attempted to achieve with TeX. I go to my personal Google maps not knowing from minute to minute if the UI will continue to work as I last used it. Is that a good direction?
From a modern software engineering perspective, the underlying TeX macro language is a frustrating pile of crap. But I accept the reason, in the same vein as I accept Stroustrup's decision for C++ to remain compatible with C, even though bolting C++ abstractions onto the C style declaration syntax remains an undying source of ugliness and detraction.
In Knuth's case, much of this was driven by his long-ago determination that TeX should function as a one-pass system. It was a practical reality at the time he wrote TeX that it functioned this way given the size of the TAOCP manuscript, and Knuth's personal work style.
Knuth was quite open that he is largely opposed to programming by maintenance, but welcomes re-purposing and adaptation.
Is the grass greener on the other side of the fence? On the other side of the fence, we have expat, Jade and DSSSL, to which few of the same criticisms apply. Panacea? I think not. Nor do I think any less of James Clark for having brought it to fruition.
I don't look to the giants among us to pave the road of convenience. I look to the giants among us to illuminate what is possible. It's when the gold brickers arrive from the private sector that I succumb to ennui. Except when I'm the gold bricker myself. Then I become strangely fascinated with my own reflection in the mirror, as if my every keystroke is a clarion click of eternal significance.
It's a rare day at the office when the significance of my work output surpasses the most boring paragraph in the TAOCP.
"Bernard of Chartres used to say that we are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size."
Then along comes the noble idiot who declares "the view is just as good, and life is more comfortable, standing on this loose pile of shifting rocks".
I deviated from the profession of mathematics long ago, but as far as I'm concerned, the question of invented/discovered was adequately retired by Kolmogorov-Chaitin complexity theory. For some reason, most mathematicians and most physicists seem determined to ignore this.
The formal system you begin with has an arbitrary beginning: the nature of the universal computer used to measure sequence length. In practice, the arbitrary starting point rarely makes a whiff of difference. The maximum disagreement on sequence length is bounded by the complexity of the program by which one machine is able to simulate the other. Since it is possible to construct universal computers of startlingly low complexity (you could easily write out the rules on the back of a business card with a blunt pencil), this bound tends to be minuscule for most universal machines we might choose to adopt for serious purposes.
I recall reading an article, by Putnam I think, where he talks about two different axiomatic formulations of the integers. Both formalisms agree on all the properties of the integers we regard as essential. However, in one system it is always true that if n < m then the set used to represent n id a subset of the set used to represent m. It the other axiomatic foundation, this is not true.
Some foundation points can introduce some strange discrepancies, but rarely anything we regard as material. This could probably be stated as an theorem in complexity theory. You'd have to put some elbow grease into the project to come up with a universal machine which can't compute pi using a "short" program where short is less than say Ackermann(4,4) and more likely, within a golf score of Ackermann(3,4).
Strange fact I didn't know:
http://en.wikipedia.org/wiki/Ackermann_function
Perhaps this is why KC theory is so often ignored. People can't wrap their minds around A(4,4) as an example of an extremely small number. The problem is, the philosophical question of invented/discovered demands this cognitive shift. A(4,4) is *not* a large number on the *philosophical* landscape.
Chaitin's omega, however, is the total perspective vortex of theoretical mathematics.
There seems to be a small number of special constants, such as e and pi, that any universal computer anyone has ever found a use for can obtain from a short program. Within this nucleus, a nanoscopically small filagree in the multidimensional fractal of all possible mathematics, the balance shifts toward "discovered". The further one departs from this minute filigree of felicity and virtue, the more the scale tips toward "invented".
If that sounds like fluff, answer this: what is the shortest number one can copyright?
Due to subitization it has never been possible to copyright the integers 1..4. The copyright on 5 probably expired 50,000 years ago. In modern society, there is evidence that 128-bit numbers remain fair game, though the difficulties of enforcing this are notorious. Clearly, five was discovered, the AACS constant was invented.
Not everyone agrees with Chaitin. This post makes a coherent statement of what he might be presuming:
http://coding.derkeiler.com/A
I wouldn't say C or C++ is losing ground. They both continue to serve well in the niches they established.
Meanwhile, other segments of the pie are expanding, and few of these new applications are coded in C or C++. Does that mean C and C++ are losing ground?
There is no language out there that serves as a better C than C, or a better C++ than C++. The people who carp about C++ reject the C++ agenda, which is not to achieve supreme enlightenment, but to cope with any ugly reality you throw at it, across any scale of implementation.
For those who wish to gaze toward enlightenment, there is always Java. Enlightenment is on the other side of a thick, protective window, but my isn't the view pretty? I've yet to encounter an "enlightened" language that offers a doorway rather than a window seat. I would be first in line if the hatch ever opened.
The problem with C/C++ has long been that the number of programming projects far exceeds the number of people who have the particular aptitudes that C/C++ demand: those of us who don't need (or wish) to be protected from ourselves (or the guy programming next to us).
It's not economically practical to force programmers who don't have that temperament to begin with to fight a losing battle with self-imposed coding invariants. I'm glad these people have other language choices where they can thrive within the scope of their particular gifts. I don't feel my role is diminished by their successes.
For those of us who have gone to the trouble to cultivate hardcore program correctness skills, none of the supposed problems in the design of C or C++ are progress limiting factors, not within the zone of applications that demand a hardcore attitude toward program correctness.
It's the natural order of things that hardcore niches are soon vacated by those unsuited to thrive there, leaving behind a critical core of people who specialize in deep-down nastiness.
For example, it's not just anyone who maintains a root DNS server. I can say with some assurance that the person who does so did not earn his (or her) grey hairs by worrying about whether the implementation language supported automatic GC.
Let's take a metaphor from the security sector. Ten years ago, a perimeter firewall was considered a good security measure. This measure alone eliminated 99% of TCP/IP based remote exploits.
These days, most exploits are tunneled through http, or maybe I'm behind the times, and the true threat is now regarded to be some protocol tunneled within http.
Then some genius comes along and says "in the security sector, TCP/IP defenses are losing ground". Quoi? Actually, no one is out there dismantling their TCP/IP based perimeter firewall. It's continuing to do the same essential job as ever.
It's only the bandwagon that has picked up and moved camp. Yes, garbage collection and deep packet inspection are now all the rage. So it goes.
Why not go around saying that sexual reproduction is all the rage these days? Would that imply we could eliminate all the organisms that reproduce asexually, and the earth's ecology would continue to function? Hardly.
These new languages are soaking up much of the new code burden because these language are freed from having to cope with the nastiness at the extremes (small and large) that C/C++ have already taken care of.
I would almost say that defines a success criteria for a programming language: if it removes enough nastiness from the application space, that the next language that comes along is free to function on a higher plane of convenience. C/C++ have both earned their stripes. Which of these new languages will achieve as much?