The "US government" isn't a person, it's composed of people who are just trying to do what's best for their campaign contributers. (Just wanted to make sure it didn't slip past anyone's irony detector.)
It's also interesting that given the choice of making relatively small changes to the law versus coughing up fines, the U.S. is consistently choosing to pay fines. As I understand it, the fines don't actually come directly out of lawmakers' bank accounts, but also affect a number of citizens who weren't even involved in the violation. Shocking!
One thing I've noticed in the few years I've been using Ubuntu is that each release quietly fixes at least one major annoyance -- drivers, multimedia, configuration, etc. Since Ubuntu 8.04 will be released on April 22, you might try a clean install of that and see if it fixes some of your problems. If not, then I agree with the other commenter who recommended Ubuntu Forums.
Programming: It sounds like you're interested in lower-level systems programming. A good book is "Linux Application Development" by Michael K. Johnson and Eric W. Troan. Most of the GNU and Gnome stuff is actually done in C, not C++, and GNU offers a thorough tutorial on C for the uninitiated. For C++, if you're committed to learning it, try "Effective C++" and "More Effective C++"; bookmark the standard library reference, and -- I notice you haven't listed any object-oriented languages -- read the "Case Study" section of the book "Design Patterns". Another language that you may find more enjoyable, and which occurs pretty regularly in GNU/Linux and especially Ubuntu, is Python.
IDEs: Eclipse is popular. Anjuta is very Gnome-ish and forms a nice collection of all the various programming utilities (autotools, gettext, glade, lint, indent,...) that are worth getting to know. I actually just use GVim and the command-line tools -- if you're used to mainframes, you might be happy with that already.
2. Windows gets its value as a platform because of the apps written for it, not because of any inherent awesomeness in the API and supporting low-level tools. So charging for the userland alone should bring in almost as much money as charging for the whole OS.
3. Windows Genuine Advantage is broken; user apps can be modified to call home and check for updates/certification regularly as part of their normal functionality, but a base platform will have problems if it has to do that successfully in order to work. (The OS is used in too many different ways.)
Solution: Make the basic Windows platform a cheap or free commodity, too, to prevent any mass exodus. Build WGA-like restrictions into the valuable apps, and then Microsoft has the ability to enforce any subscription model they please. Since it's only an app and not the whole OS that gets the remote touch-of-death for failing to call home properly, some of the problems with the original WGA scheme go away. Profit!
Redesigning the OS to actually function this way is another matter, of course -- the plan only works if the new platform runs all of the same software and hardware that the old one did.
Part of the Zen of Python is: "Errors should never pass silently. Unless explicitly silenced." So, for example, there are some kinds of type coercion that Python will throw a noisy exception for, even when a human reader would probably be able to figure out what the code was intended to do -- like adding an integer to a string. That's part of the appeal of statically typed languages like Java -- some ambiguities won't even compile, so it's impossible to let those particular errors go into production.
Like HTML (and unlike XHTML), Javascript tries to limp along as much as possible when it encounters ambiguous code. So the expression "You collected " + bugs + " bugs.", where bugs is an integer, will turn bugs into a string and concatenate the strings. In C, adding an integer to a character will increase the ASCII value of the character by the amount of the integer ('a'+5 -> 'f'), so we can see that adding integers and strings is an ambiguous and therefore error-prone process. Tons of websites, even high-profile ones, have lots of errors in their Javascript passing silently, and they work anyway.
Given how the Web works, that's probably the right decision for Javascript. It fits with the idea of graceful degradation. You shouldn't be angry at Javascript at all. But this leniency does mean that just because a script runs, doesn't mean it's not full of errors. And just because you can build a website that uses client-side Javascript, doesn't mean you know the language well enough to build a reliable server-side app in it.
But given that history of C#, Java, C++, and any other popular programming language, I disagree that the leniency in Javascript's spec is the main cause of the low signal-to-noise ratio in Javascript programmers. Really, I think it's just because everyone has access to a Javascript interpreter in their browser, and disciplined programmers are a tiny subset of "everyone."
Depending on how you use your computer, a shortage of memory can really slow you down. Try watching the CPU meter too; you might not be maxing that out either. When a normal user sees a computer behaving sluggishly, it's usually because the computer is pushing data around, not necessarily doing much processing on it. Pulling data from memory is much slower than working with the relatively tiny amount of info already in the CPU's registers; swapping data between RAM and a hard drive is orders of magnitude slower than even that. And there are plenty of tricks operating systems use to manage memory, so what you see in Task Manager may not be the whole story.
The way some people use Firefox, with multiple extensions running, plugin-heavy pages and a (few) dozen tabs open, it's possible to get well over 500 MB even without the help of memory leaks. The memory-leak bugs also tend to be architecture-dependent, so the same Firefox session that seems OK on your XP/Intel box might trigger a memory blowup on a minority platform. The way memory is actually allocated is managed by a mix of the OS, the way the app is written, and the compiler, so tracking down why memory is being used a certain way is difficult. In the case of Firefox there's also the code in extensions, plugins, and the Javascript on each site to keep things interesting... I too would cringe at a bug report that says Task Manager shows Firefox using too much RAM.
Normally when someone complains their computer is brutally slow, I advise (a) reinstalling Windows if it's been a few years, and/or (b) adding more RAM. (And if the response is "do it for me", I usually whip out the Ubuntu disk and start a frank discussion.) The CPU is rarely the real problem in normal usage -- heavy CPU processing usually has an obvious purpose, but a slow CPU won't cause the random 30-second lags that Users seem to encounter after a few years of Using.
Given that the military dispenses information on a need-to-know basis, I expected "this answer intentionally left blank" for most of these questions. Instead, I gleaned the following:
1. The AFCC operates like the X11 API: providing capability, but not policy. (The comparison might not end there.)
2. Much like an ideal gas, the military will expand to fill the available legal space completely. They have little interest in guiding or creating legislation -- the less, the better, as long as funding is available. If we don't want the AFCC involved in something, the only way to stop it is for Congress or the executive branch to specifically block it.
3. Recruiting genuinely good security personnel will be done through private contractors. The armed forces doesn't currently have a good way to integrate hacker culture, so for now, they're letting outside parties handle those projects.
4. Top brass does care somewhat about security, since it's actually really important. Lower brass cares about completing big flashy projects, and security is generally not flashy. The tiers have not been communicating well on this topic, and some heads need to be cracked, apparently. (And god only knows what is happening inside the contractor companies. Lord sure doesn't.)
Nor do normal users really care about this kind of exploit in general. This information is useful for site administrators who actually can do something about the problem, where it matters.
Certainly it's not the appeal in California and New York that matters, it's the appeal in swing states in the Midwest. Hillary's states will vote Democratic no matter what; it's states like Ohio and Colorado that will decide the winner in November.
Krugman is right that the Clinton plan is a much better way to get universal coverage. But if Obama wins, that plan won't just vanish in a puff of smoke; Congress (who actually draft the bill) will still have access to it. And, the key strength of the plan -- a mandate requiring everyone to have insurance -- will probably be a weakness in getting the bill past small-government Republicans.
Google has 4 times the search hits of yahoo and is growing. The breakdown of search hits reported by comScore is:
52.6% Google sites
26.9% Yahoo sites
10.4% Microsoft sites
In the article, it says Google has 75% of the worldwide search revenue, and awkwardly implies that Microsoft and Yahoo take another 20% together. Elsewhere, I've seen that in terms of unique visitors, Google is only slightly higher than MS. Together, I think these numbers mean: - Google is much better than MS and Yahoo at converting searches into money - Lots of people have Yahoo or MSN as their startup page but don't do searches from there - Either Yahoo and MSN users don't know how to do online searches (unlikely), or a large number of them use Google for searches despite having a search box already on their homepage
Incidentally, Google's stock price fell when the bid was announced, so investors (note that Yahoo Finance is a pretty definitive hub for market info) don't see Yahoo as a lead balloon currently. That doesn't mean it isn't a lead balloon (given that its stock price was $18 and the article values the company's assets at $39-45 a share), but if the two companies merge they'll float along on investor money for awhile regardless.
I suppose I was really referring to the point where the average new low-end computer has at least 4 MB RAM included. With most of the usual desktop apps moving online, it's still possible to get by with much less than that and still not feel deprived. When 4 MB is the minimum for normal computer use, especially office use, there will be some hard selective pressure on 64-bit operating systems. I've had zero experience with 64-bit Vista, but 64-bit Linux systems appear to be ready to go.
The approach to parameter typing (optional and unenforced) is silly. Having it and not enforcing it is just asking for trouble.
Python allows all these things, which can occasionally be useful. The trouble is that it's really tough to tell at compile time if the hard cases are going to be needed, and thus code has to be pessimized for the worst case. I think the language you're looking for is here.
It's not optional parameter typing, it's parameter annotation. Libraries can figure out something useful to do with them, e.g. documentation generators or FFIs, but the language by default doesn't care. Usually the annotations won't be used. Declared types are certainly not the way Python intends to go.
* Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during compilation, assign them fixed slots, and avoid having a dictionary in each object. If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about. Prior to Python 2.2 (I think), there were "classic-style" classes that were, well, just ordinary classes. Dynamic structures. Python then introduced "new-style" classes that all implicitly derived from object. We've known since Smalltalk that it's useful for "everything" to be "an object", but Python didn't get around to implementing that properly until to 2.x series, and then had to keep old-style classes around for compatibility. Python 3.0 finally gets it right and eliminates old-style classes, so everything will in fact be an object. What you're looking for is something like "Object" and "StaticObject". So if you happen to derive from a StaticObject instead of an Object, you'll be surprised to find you're limited in the things you can do, and your options are to hack a dictionary onto your new object, or reimplement the parent class as an Object. Eventually you clue up and rewrite everything as an Object. The whole motivation of dynamically typed languages is that flexibility beats performance.
The point of monkeypatching is that the original class definition didn't expect to be modified. So, why would expect that the author knows when deriving from Object is necessary instead of DynamicObject? It's the fragile base class problem, squared.
* Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic. Or you could take the approach that variables don't have types; values do. In which case the restriction is silly. Common Lisp takes this approach, and programs compiled with SBCL are about the same speed as Java.
This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations. I think the language you're looking for is here.
Some things need it, some things don't. For languages, it really helps to clean up old cruft to make the language more consistent, and sometimes it makes compilation easier by getting rid of awkward special cases. Ruby took the approach of making the crazier additions in 1.9, so that 2.0 will be able to decide what's worth keeping (which I think means they'll throw some cruft way too). Even C cleaned things up a little in the C99 spec. These definitely aren't full rewrites, though, like Perl 6.
For compilers and interpreters it's a little different. They can complain loudly when they run across a deprecated feature, but usually there needs to be some way to run older code. I know I often see a few warnings when compiling some apparently stable library, but I still want it to compile. GTK2 still handles a ton of deprecated stuff from the GTK1 days.
I draw the (blurry) line between features and infrastructure: A Firefox extension can change completely whenever it wants; Firefox itself hurts a little when it changes, but mostly just while the extensions get sorted out; and Gecko still needs to be able to handle HTML 1.0.
In Linux there are a few ways to do it, depending on how your system is set up.
A. If you have Python 2.6 installed at/usr/bin/python (the usual spot), make sure the environmental variable for python is pointing to that. The "portable" way to do the shebang is #!/usr/bin/env python, so if/usr/bin/env python points to python2.6, you're fine. If you want to run Python 3.0 by default, make/usr/bin/env python point to python3.0.
B. If you want to play with Python 3.0 without clobbering Python 2.6, install Py3.0 to another location like your home directory. Put #!/usr/bin/env python3.0 at the top of your scripts, or run them from the terminal as python3.0 myscript.py.
C. If you have Py3.0 as the default (/usr/bin/env python), and you want to run a certain script as Py2.6, use python2.6 myscript.py from the shell or #!/usr/bin/env python2.6 at the top of the script.
D. If you're lazy, #!python3.0 and #!python2.6 also usually work without the/usr/bin/env.
But as they say in a bunch of other places, you can keep writing 2.6-compatible scripts and using the built-in 2to3 converter to generate 100% 3.0-friendly equivalents until you're ready to make the switch.
(In Linux, the file type is normally figured out from the contents of the file, particularly the first two bytes, instead of the extension. Some window managers will look at the extensions, too, but they'll still figure it out if you have a GIF file that happens to end in.jpg (for example).)
Think about what was happening in those two examples -- the whole language was ported to a new runtime that didn't even exist when the language was first designed, and VB's implementation was kludgey and brittle to begin with. Plus, Microsoft's motivation was more in pushing.NET than in winning new VB converts by showing a commitment to backward compatibility. And, it's Microsoft. C'mon.
The number of concepts that change in Python 2.0 -> 3.0 is tiny. The main thing that will break everyone's code without the converter is that print changes from a statement to a function, so you need to parentheses everywhere. The rest is removing long-deprecated hacks, making Unicode the default, rearranging the library a bit, making module imports more explicit, and making built-in functions that returned lists instead return iterators, to save memory. All these changes have direct equivalents in the 2.x series. Some concepts are added, too, but that shouldn't be a problem for 2.x code.
This all means that the converter will actually work. For VB, the best they could claim was that 90% of the port would be automatic; for Python's 2to3 conversion tool (included with the installation), it's expected that you can maintain a clean 2.6 codebase and automatically generate 3.0 code as needed until you're ready to switch to 3.0 full-time.
Also, the plan for a backwards-incompatible Python 3.0 has been public for years. As if the incremented major version number wasn't a clue. Why the furor now? I don't recall seeing a story called "KDE4 introduces changes; Earth dying". A release manager made a flippant remark about compatibility, and a tech reporter sniffed blood, that's all.
That points will be a few years away. Python 2.6 is going to be released in April, and there will also be a 2.7, 2.8 and probably 2.9.
Here's what Guido said here on July 27, 2007:
Q. I want to learn Python. Should I learn Python 2.6 or Python 3.0?
A. Definitely learn Python 2.x (the latest version out is 2.5). I expect it'll be two years before you'll need to learn Python 3.0, and the differences aren't that great from a beginner's perspective: most of what you'll learn about 2.x will still hold about 3.0. Mid-2009 isn't so bad, and I think what he means is that's when operating systems will start including 3.x by default. Remember -- Guido works for Google now, and last I heard, Google was still using Python 2.2.
Every time I hear about the Year Of Linux, I think of this: World Domination 201
According to Eric Raymond, YoL = 2008, originally calculated in 2003 to be the year everyone switches to 64-bit. In theory, even low-end buyers would be getting 64-bit machines this year, and the race would be between Microsoft getting every hardware vendor on the planet to update all their drivers, Apple releasing an operating system for the masses (meaning, cheap commodity hardware), and Linux basically just being usable and keeping its source code open and 64-bit clean.
So far, 64-bit Vista is its own saga, Apple's new lightweight laptop costs $1,800, and in Linux's corner -- KDE 4, Ubuntu, and lots of love from hardware manufacturers, IBM and Sun.
While high-end computers are definitely in 64-bit territory now, I think the low end these days would be happy to dwell on 32-bit machines awhile longer -- which actually works in Linux's favor, since open-source development overall seems to be progressing much faster than whatever's going on internally at Microsoft.
Coincidence, maybe? I don't expect a reporter who names a nonexistent version to have gone to the trouble of counting all the releases, but losing the 1 in 7.10 is an easy typo. Either way, that's probably the version they mean since 7.10 is also the version Dell is shipping now.
Warty, Hoary, Breezy, Dapper, Edgy, Feisty, Gutsy By the way, the Ubuntu releases look like dwarves when you list them that way.
The suspicious thing about the 2/3 drop in cash is that the stock price hasn't changed much over the same term. On July 2 2004 the price was about $28.57; on July 2 2007 it was $29.74. The first price was during the lull between XP's release and the (expected) release of Longhorn, while the second price should have been pumped up by the actual release of Vista -- that should more than account for the 4% gain over the same period. A rise of 4% over 3 years doesn't even cover inflation, much less the release of major new versions of the two core products, stock buybacks, big dividends, and wherever else that $40 billion went.
I don't doubt that they spent the cash on purpose, but they should have something to show for it.
The stock price exploded at the end of October after Microsoft released revenue guidance for Q2 FY2008, but it's been dwindling back down since then, and the U.S. economy is unlikely to be very favorable for any business during the next few months. GOOG, AAPL, YHOO, NOVL and JAVA have similarly been taking a crap this month -- it would take some serious voodoo for MSFT to actually rise in this kind of environment.
in my 7 years of professional programming, I've seen 2 Python programs. One was an app the author wrote to try out Python, the other we rewrote in Perl. If your CV says you're a pro in Perl (which I assume you are, since you've rewritten other stuff in it), you're probably going to end up at Perl-friendly companies, possibly referred by buddies who hacked Perl with you in the past. As a programmer it's almost impossible not to end up in a niche of some sort -- so far I've managed to avoid both Java and C# (narrowly), though I've done plenty of Python and C/C++, and I know other professional programmers who never see anything but Actionscript and VB.NET.
Python is actually overshadowing Perl in high-profile open-source work now -- it's installed by default on new Macs and most Linux distros, and it's the main language for OLPC's XO, much of the Gnome project, most of what Canonical does on its own, and of course Google. I know Perl is still holding strong in business and academic research (and Slashcode), but programmers with the opportunity to choose the language they'll write in seem to be choosing Python fairly regularly now.
If Microsoft were really having to compete, they would not have accumulated a mountain of cash. They would have either been forced to lower prices or plow that money into development. It's true that Microsoft has a suspiciously large... war chest. Another option would be for them to buy back a chunk of company stock -- they've been ticking up for the last couple of years, but the stock price is still a quarter of what it was in 2001. (Maybe there was a split I didn't notice.) Regardless, MSFT is no longer among the best-performing tech stocks, and shareholders have got to be jealous of the gains GOOG and AAPL made last year. Maybe Microsoft could time a buyback so that a jump in stock price coincides with the release of Vista SP1, making it look like all the business users really were just holding out for the service pack...
But they won't drop prices for Windows or Office on account of it, since they're a monopoly and they can charge whatever the market will bear. And they're plowing plenty of it into development, but it's hard to shift focus away from a cash cow even when it's clear the commercial environment is changing. And as for current development: "Adding more developers to a late project makes it later," right? The Windows and Office teams are clearly maxed out, while the research and.Net teams are cranking out new tools (and deprecating old ones) faster than outside developers can learn how to use them.
Regardless of how much cash they're taking in right now, I don't plan on buying any MSFT shares in the foreseeable future.
It gives Dell something to do in the customization step, too. When I set up Ubuntu+XP for my parents, I added a shortcut/bookmark in Nautilus and the Places menu to the "My Documents" folder on the XP partition (rw access). So all their documents are available from both OSes, they don't need to learn much about user home directories, Dad has easy access to Excel, and Mom isn't plagued by the various anti-productivity measures built into Windows and Norton Antivirus For Home Victims.
This has been a good solution for them so far, and I think I'd recommend it for general use. It might be even better to symlink ~user/.mozilla to %ApplicationData%/Mozilla, to share extensions and bookmarks, but I haven't tried it.
Not sure if offering dual-boot out of the box is even the best option, really. I think the most effective thing Dell could do for Linux would be to list usable Ubuntu laptops on the same pages and in the same categories as the Windows Vista laptops for home and business users -- Vista isn't cheap, and home laptop prices are dropping quickly, so the comparison could be very compelling for customers.
It's even cleaner in Scheme. (Just saying.) And, your code doesn't handle attributes or empty tags properly. But it's true that the Python equivalent would need to make some compromises to avoid getting completely hairy -- starting by either putting the HTML pseudocode into a string or throwing parentheses all over the place.
DSLs aren't Python's strong point. Some options are: - Some string transformations, then eval() - A recursive operation on a dictionary, since HTML in particular kind of fits that model - Just use a library like xml.etree for whatever you were actually trying to do (I know, that's just what a Java programmer would say) - Full-blown parser and interpreter, with some help from the standard library
But the specific case isn't that interesting. Almost all of the capabilities (not necessarily basic features) are the same between the latest incarnations of Ruby, Python, Perl, and JavaScript -- where one's missing a feature, there tends to be at least a workaround.
The main difference between Ruby and Python is that Guido doesn't like functional programming, but really likes structured C, Unix, and teaching languages. Matz seems to really like Common Lisp and Smalltalk, but recognizes the need to git 'er done, Perl-style, too. Guido's background is in big organizations; Matz's is in compilers. They're both brilliant.
So Python code looks almost exactly like C pseudocode, and the real-world code often looks just as clean as the tutorial examples (in contrast to, say, C++). If you write something that runs correctly and efficiently in Python, it will generally look reasonable to any other programmer, too.
Ruby instead takes every standard programming style and makes it easy to express an idea that way. If you already understand FP, OOP, etc., it's incredibly expressive. I think an experienced, well-rounded hacker tends towards Ruby... but a company like Google is sane for mandating that their gargantuan codebase, written by thousands of adventurous coders with differing styles and tastes, should be mostly Python.
This has been going on since at least the mid-1970s, so if this is a prank, there are some extremely dedicated rednecks in Death Valley. I bet the area was even named "Racetrack Playa" because of these rocks and the tracks they made, back when it was discovered. The rocks only scoot around once every few years, apparently, but there are a lot of rocks and it looks like they all have trails.
Well, Ubuntu releases are only 6 months apart. I'd probably be annoyed if the upgrade was a major change to my workflow. Apple's release cycle seems to be striking a happy medium between "large enough to be worth upgrading" and "small enough not to hurt productivity after the upgrade".
Of course, as upgrading becomes cheaper and less of a hassle on that scale, the ideal upgrade cycle becomes shorter. For something as disruptive as Vista you might as well wait until you need a new computer; for a Linux distro where dist-upgrade is free, automated and all online, frequent small upgrades are fine.
(NB: A more accurate comparison for Ubuntu is between Gutsy and Hoary Hedgehog, which was released the same month as Tiger. The difference: In 2005 every Linux still required geek-fu; today it's on Dells and in Wal-Mart.)
Slashdot Mirror
It's also interesting that given the choice of making relatively small changes to the law versus coughing up fines, the U.S. is consistently choosing to pay fines. As I understand it, the fines don't actually come directly out of lawmakers' bank accounts, but also affect a number of citizens who weren't even involved in the violation. Shocking!
One thing I've noticed in the few years I've been using Ubuntu is that each release quietly fixes at least one major annoyance -- drivers, multimedia, configuration, etc. Since Ubuntu 8.04 will be released on April 22, you might try a clean install of that and see if it fixes some of your problems. If not, then I agree with the other commenter who recommended Ubuntu Forums.
...) that are worth getting to know. I actually just use GVim and the command-line tools -- if you're used to mainframes, you might be happy with that already.
Programming: It sounds like you're interested in lower-level systems programming. A good book is "Linux Application Development" by Michael K. Johnson and Eric W. Troan. Most of the GNU and Gnome stuff is actually done in C, not C++, and GNU offers a thorough tutorial on C for the uninitiated. For C++, if you're committed to learning it, try "Effective C++" and "More Effective C++"; bookmark the standard library reference, and -- I notice you haven't listed any object-oriented languages -- read the "Case Study" section of the book "Design Patterns". Another language that you may find more enjoyable, and which occurs pretty regularly in GNU/Linux and especially Ubuntu, is Python.
IDEs: Eclipse is popular. Anjuta is very Gnome-ish and forms a nice collection of all the various programming utilities (autotools, gettext, glade, lint, indent,
That sounds about right.
1. Linux and BSD made Unix a commodity platform.
2. Windows gets its value as a platform because of the apps written for it, not because of any inherent awesomeness in the API and supporting low-level tools. So charging for the userland alone should bring in almost as much money as charging for the whole OS.
3. Windows Genuine Advantage is broken; user apps can be modified to call home and check for updates/certification regularly as part of their normal functionality, but a base platform will have problems if it has to do that successfully in order to work. (The OS is used in too many different ways.)
Solution: Make the basic Windows platform a cheap or free commodity, too, to prevent any mass exodus. Build WGA-like restrictions into the valuable apps, and then Microsoft has the ability to enforce any subscription model they please. Since it's only an app and not the whole OS that gets the remote touch-of-death for failing to call home properly, some of the problems with the original WGA scheme go away. Profit!
Redesigning the OS to actually function this way is another matter, of course -- the plan only works if the new platform runs all of the same software and hardware that the old one did.
Part of the Zen of Python is: "Errors should never pass silently. Unless explicitly silenced." So, for example, there are some kinds of type coercion that Python will throw a noisy exception for, even when a human reader would probably be able to figure out what the code was intended to do -- like adding an integer to a string. That's part of the appeal of statically typed languages like Java -- some ambiguities won't even compile, so it's impossible to let those particular errors go into production.
Like HTML (and unlike XHTML), Javascript tries to limp along as much as possible when it encounters ambiguous code. So the expression "You collected " + bugs + " bugs.", where bugs is an integer, will turn bugs into a string and concatenate the strings. In C, adding an integer to a character will increase the ASCII value of the character by the amount of the integer ('a'+5 -> 'f'), so we can see that adding integers and strings is an ambiguous and therefore error-prone process. Tons of websites, even high-profile ones, have lots of errors in their Javascript passing silently, and they work anyway.
Given how the Web works, that's probably the right decision for Javascript. It fits with the idea of graceful degradation. You shouldn't be angry at Javascript at all. But this leniency does mean that just because a script runs, doesn't mean it's not full of errors. And just because you can build a website that uses client-side Javascript, doesn't mean you know the language well enough to build a reliable server-side app in it.
But given that history of C#, Java, C++, and any other popular programming language, I disagree that the leniency in Javascript's spec is the main cause of the low signal-to-noise ratio in Javascript programmers. Really, I think it's just because everyone has access to a Javascript interpreter in their browser, and disciplined programmers are a tiny subset of "everyone."
Depending on how you use your computer, a shortage of memory can really slow you down. Try watching the CPU meter too; you might not be maxing that out either. When a normal user sees a computer behaving sluggishly, it's usually because the computer is pushing data around, not necessarily doing much processing on it. Pulling data from memory is much slower than working with the relatively tiny amount of info already in the CPU's registers; swapping data between RAM and a hard drive is orders of magnitude slower than even that. And there are plenty of tricks operating systems use to manage memory, so what you see in Task Manager may not be the whole story.
The way some people use Firefox, with multiple extensions running, plugin-heavy pages and a (few) dozen tabs open, it's possible to get well over 500 MB even without the help of memory leaks. The memory-leak bugs also tend to be architecture-dependent, so the same Firefox session that seems OK on your XP/Intel box might trigger a memory blowup on a minority platform. The way memory is actually allocated is managed by a mix of the OS, the way the app is written, and the compiler, so tracking down why memory is being used a certain way is difficult. In the case of Firefox there's also the code in extensions, plugins, and the Javascript on each site to keep things interesting... I too would cringe at a bug report that says Task Manager shows Firefox using too much RAM.
Normally when someone complains their computer is brutally slow, I advise (a) reinstalling Windows if it's been a few years, and/or (b) adding more RAM. (And if the response is "do it for me", I usually whip out the Ubuntu disk and start a frank discussion.) The CPU is rarely the real problem in normal usage -- heavy CPU processing usually has an obvious purpose, but a slow CPU won't cause the random 30-second lags that Users seem to encounter after a few years of Using.
Given that the military dispenses information on a need-to-know basis, I expected "this answer intentionally left blank" for most of these questions. Instead, I gleaned the following:
1. The AFCC operates like the X11 API: providing capability, but not policy. (The comparison might not end there.)
2. Much like an ideal gas, the military will expand to fill the available legal space completely. They have little interest in guiding or creating legislation -- the less, the better, as long as funding is available. If we don't want the AFCC involved in something, the only way to stop it is for Congress or the executive branch to specifically block it.
3. Recruiting genuinely good security personnel will be done through private contractors. The armed forces doesn't currently have a good way to integrate hacker culture, so for now, they're letting outside parties handle those projects.
4. Top brass does care somewhat about security, since it's actually really important. Lower brass cares about completing big flashy projects, and security is generally not flashy. The tiers have not been communicating well on this topic, and some heads need to be cracked, apparently. (And god only knows what is happening inside the contractor companies. Lord sure doesn't.)
Nor do normal users really care about this kind of exploit in general. This information is useful for site administrators who actually can do something about the problem, where it matters.
Judging by your mod point so far, only one other ./er even noticed that. Articles? We don't need no stinkin' articles!
Certainly it's not the appeal in California and New York that matters, it's the appeal in swing states in the Midwest. Hillary's states will vote Democratic no matter what; it's states like Ohio and Colorado that will decide the winner in November.
Krugman is right that the Clinton plan is a much better way to get universal coverage. But if Obama wins, that plan won't just vanish in a puff of smoke; Congress (who actually draft the bill) will still have access to it. And, the key strength of the plan -- a mandate requiring everyone to have insurance -- will probably be a weakness in getting the bill past small-government Republicans.
52.6% Google sites
26.9% Yahoo sites
10.4% Microsoft sites
In the article, it says Google has 75% of the worldwide search revenue, and awkwardly implies that Microsoft and Yahoo take another 20% together. Elsewhere, I've seen that in terms of unique visitors, Google is only slightly higher than MS. Together, I think these numbers mean:
- Google is much better than MS and Yahoo at converting searches into money
- Lots of people have Yahoo or MSN as their startup page but don't do searches from there
- Either Yahoo and MSN users don't know how to do online searches (unlikely), or a large number of them use Google for searches despite having a search box already on their homepage
Incidentally, Google's stock price fell when the bid was announced, so investors (note that Yahoo Finance is a pretty definitive hub for market info) don't see Yahoo as a lead balloon currently. That doesn't mean it isn't a lead balloon (given that its stock price was $18 and the article values the company's assets at $39-45 a share), but if the two companies merge they'll float along on investor money for awhile regardless.
I suppose I was really referring to the point where the average new low-end computer has at least 4 MB RAM included. With most of the usual desktop apps moving online, it's still possible to get by with much less than that and still not feel deprived. When 4 MB is the minimum for normal computer use, especially office use, there will be some hard selective pressure on 64-bit operating systems. I've had zero experience with 64-bit Vista, but 64-bit Linux systems appear to be ready to go.
It's not optional parameter typing, it's parameter annotation. Libraries can figure out something useful to do with them, e.g. documentation generators or FFIs, but the language by default doesn't care. Usually the annotations won't be used. Declared types are certainly not the way Python intends to go. * Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during compilation, assign them fixed slots, and avoid having a dictionary in each object. If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about. Prior to Python 2.2 (I think), there were "classic-style" classes that were, well, just ordinary classes. Dynamic structures. Python then introduced "new-style" classes that all implicitly derived from object. We've known since Smalltalk that it's useful for "everything" to be "an object", but Python didn't get around to implementing that properly until to 2.x series, and then had to keep old-style classes around for compatibility. Python 3.0 finally gets it right and eliminates old-style classes, so everything will in fact be an object. What you're looking for is something like "Object" and "StaticObject". So if you happen to derive from a StaticObject instead of an Object, you'll be surprised to find you're limited in the things you can do, and your options are to hack a dictionary onto your new object, or reimplement the parent class as an Object. Eventually you clue up and rewrite everything as an Object. The whole motivation of dynamically typed languages is that flexibility beats performance.
The point of monkeypatching is that the original class definition didn't expect to be modified. So, why would expect that the author knows when deriving from Object is necessary instead of DynamicObject? It's the fragile base class problem, squared. * Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic. Or you could take the approach that variables don't have types; values do. In which case the restriction is silly. Common Lisp takes this approach, and programs compiled with SBCL are about the same speed as Java. This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations. I think the language you're looking for is here.
Some things need it, some things don't. For languages, it really helps to clean up old cruft to make the language more consistent, and sometimes it makes compilation easier by getting rid of awkward special cases. Ruby took the approach of making the crazier additions in 1.9, so that 2.0 will be able to decide what's worth keeping (which I think means they'll throw some cruft way too). Even C cleaned things up a little in the C99 spec. These definitely aren't full rewrites, though, like Perl 6.
For compilers and interpreters it's a little different. They can complain loudly when they run across a deprecated feature, but usually there needs to be some way to run older code. I know I often see a few warnings when compiling some apparently stable library, but I still want it to compile. GTK2 still handles a ton of deprecated stuff from the GTK1 days.
I draw the (blurry) line between features and infrastructure: A Firefox extension can change completely whenever it wants; Firefox itself hurts a little when it changes, but mostly just while the extensions get sorted out; and Gecko still needs to be able to handle HTML 1.0.
In Linux there are a few ways to do it, depending on how your system is set up.
/usr/bin/python (the usual spot), make sure the environmental variable for python is pointing to that. The "portable" way to do the shebang is #!/usr/bin/env python, so if /usr/bin/env python points to python2.6, you're fine. If you want to run Python 3.0 by default, make /usr/bin/env python point to python3.0.
/usr/bin/env.
.jpg (for example).)
A. If you have Python 2.6 installed at
B. If you want to play with Python 3.0 without clobbering Python 2.6, install Py3.0 to another location like your home directory. Put #!/usr/bin/env python3.0 at the top of your scripts, or run them from the terminal as python3.0 myscript.py.
C. If you have Py3.0 as the default (/usr/bin/env python), and you want to run a certain script as Py2.6, use python2.6 myscript.py from the shell or #!/usr/bin/env python2.6 at the top of the script.
D. If you're lazy, #!python3.0 and #!python2.6 also usually work without the
But as they say in a bunch of other places, you can keep writing 2.6-compatible scripts and using the built-in 2to3 converter to generate 100% 3.0-friendly equivalents until you're ready to make the switch.
(In Linux, the file type is normally figured out from the contents of the file, particularly the first two bytes, instead of the extension. Some window managers will look at the extensions, too, but they'll still figure it out if you have a GIF file that happens to end in
Think about what was happening in those two examples -- the whole language was ported to a new runtime that didn't even exist when the language was first designed, and VB's implementation was kludgey and brittle to begin with. Plus, Microsoft's motivation was more in pushing .NET than in winning new VB converts by showing a commitment to backward compatibility. And, it's Microsoft. C'mon.
The number of concepts that change in Python 2.0 -> 3.0 is tiny. The main thing that will break everyone's code without the converter is that print changes from a statement to a function, so you need to parentheses everywhere. The rest is removing long-deprecated hacks, making Unicode the default, rearranging the library a bit, making module imports more explicit, and making built-in functions that returned lists instead return iterators, to save memory. All these changes have direct equivalents in the 2.x series. Some concepts are added, too, but that shouldn't be a problem for 2.x code.
This all means that the converter will actually work. For VB, the best they could claim was that 90% of the port would be automatic; for Python's 2to3 conversion tool (included with the installation), it's expected that you can maintain a clean 2.6 codebase and automatically generate 3.0 code as needed until you're ready to switch to 3.0 full-time.
Also, the plan for a backwards-incompatible Python 3.0 has been public for years. As if the incremented major version number wasn't a clue. Why the furor now? I don't recall seeing a story called "KDE4 introduces changes; Earth dying". A release manager made a flippant remark about compatibility, and a tech reporter sniffed blood, that's all.
Here's what Guido said here on July 27, 2007: Q. I want to learn Python. Should I learn Python 2.6 or Python 3.0?
A. Definitely learn Python 2.x (the latest version out is 2.5). I expect it'll be two years before you'll need to learn Python 3.0, and the differences aren't that great from a beginner's perspective: most of what you'll learn about 2.x will still hold about 3.0. Mid-2009 isn't so bad, and I think what he means is that's when operating systems will start including 3.x by default. Remember -- Guido works for Google now, and last I heard, Google was still using Python 2.2.
Every time I hear about the Year Of Linux, I think of this:
World Domination 201
According to Eric Raymond, YoL = 2008, originally calculated in 2003 to be the year everyone switches to 64-bit. In theory, even low-end buyers would be getting 64-bit machines this year, and the race would be between Microsoft getting every hardware vendor on the planet to update all their drivers, Apple releasing an operating system for the masses (meaning, cheap commodity hardware), and Linux basically just being usable and keeping its source code open and 64-bit clean.
So far, 64-bit Vista is its own saga, Apple's new lightweight laptop costs $1,800, and in Linux's corner -- KDE 4, Ubuntu, and lots of love from hardware manufacturers, IBM and Sun.
While high-end computers are definitely in 64-bit territory now, I think the low end these days would be happy to dwell on 32-bit machines awhile longer -- which actually works in Linux's favor, since open-source development overall seems to be progressing much faster than whatever's going on internally at Microsoft.
The suspicious thing about the 2/3 drop in cash is that the stock price hasn't changed much over the same term. On July 2 2004 the price was about $28.57; on July 2 2007 it was $29.74. The first price was during the lull between XP's release and the (expected) release of Longhorn, while the second price should have been pumped up by the actual release of Vista -- that should more than account for the 4% gain over the same period. A rise of 4% over 3 years doesn't even cover inflation, much less the release of major new versions of the two core products, stock buybacks, big dividends, and wherever else that $40 billion went.
I don't doubt that they spent the cash on purpose, but they should have something to show for it.
The stock price exploded at the end of October after Microsoft released revenue guidance for Q2 FY2008, but it's been dwindling back down since then, and the U.S. economy is unlikely to be very favorable for any business during the next few months. GOOG, AAPL, YHOO, NOVL and JAVA have similarly been taking a crap this month -- it would take some serious voodoo for MSFT to actually rise in this kind of environment.
Python is actually overshadowing Perl in high-profile open-source work now -- it's installed by default on new Macs and most Linux distros, and it's the main language for OLPC's XO, much of the Gnome project, most of what Canonical does on its own, and of course Google. I know Perl is still holding strong in business and academic research (and Slashcode), but programmers with the opportunity to choose the language they'll write in seem to be choosing Python fairly regularly now.
But they won't drop prices for Windows or Office on account of it, since they're a monopoly and they can charge whatever the market will bear. And they're plowing plenty of it into development, but it's hard to shift focus away from a cash cow even when it's clear the commercial environment is changing. And as for current development: "Adding more developers to a late project makes it later," right? The Windows and Office teams are clearly maxed out, while the research and
Regardless of how much cash they're taking in right now, I don't plan on buying any MSFT shares in the foreseeable future.
It gives Dell something to do in the customization step, too. When I set up Ubuntu+XP for my parents, I added a shortcut/bookmark in Nautilus and the Places menu to the "My Documents" folder on the XP partition (rw access). So all their documents are available from both OSes, they don't need to learn much about user home directories, Dad has easy access to Excel, and Mom isn't plagued by the various anti-productivity measures built into Windows and Norton Antivirus For Home Victims.
This has been a good solution for them so far, and I think I'd recommend it for general use. It might be even better to symlink ~user/.mozilla to %ApplicationData%/Mozilla, to share extensions and bookmarks, but I haven't tried it.
Not sure if offering dual-boot out of the box is even the best option, really. I think the most effective thing Dell could do for Linux would be to list usable Ubuntu laptops on the same pages and in the same categories as the Windows Vista laptops for home and business users -- Vista isn't cheap, and home laptop prices are dropping quickly, so the comparison could be very compelling for customers.
It's even cleaner in Scheme. (Just saying.) And, your code doesn't handle attributes or empty tags properly. But it's true that the Python equivalent would need to make some compromises to avoid getting completely hairy -- starting by either putting the HTML pseudocode into a string or throwing parentheses all over the place.
DSLs aren't Python's strong point. Some options are:
- Some string transformations, then eval()
- A recursive operation on a dictionary, since HTML in particular kind of fits that model
- Just use a library like xml.etree for whatever you were actually trying to do (I know, that's just what a Java programmer would say)
- Full-blown parser and interpreter, with some help from the standard library
But the specific case isn't that interesting. Almost all of the capabilities (not necessarily basic features) are the same between the latest incarnations of Ruby, Python, Perl, and JavaScript -- where one's missing a feature, there tends to be at least a workaround.
The main difference between Ruby and Python is that Guido doesn't like functional programming, but really likes structured C, Unix, and teaching languages. Matz seems to really like Common Lisp and Smalltalk, but recognizes the need to git 'er done, Perl-style, too. Guido's background is in big organizations; Matz's is in compilers. They're both brilliant.
So Python code looks almost exactly like C pseudocode, and the real-world code often looks just as clean as the tutorial examples (in contrast to, say, C++). If you write something that runs correctly and efficiently in Python, it will generally look reasonable to any other programmer, too.
Ruby instead takes every standard programming style and makes it easy to express an idea that way. If you already understand FP, OOP, etc., it's incredibly expressive. I think an experienced, well-rounded hacker tends towards Ruby... but a company like Google is sane for mandating that their gargantuan codebase, written by thousands of adventurous coders with differing styles and tastes, should be mostly Python.
This has been going on since at least the mid-1970s, so if this is a prank, there are some extremely dedicated rednecks in Death Valley. I bet the area was even named "Racetrack Playa" because of these rocks and the tracks they made, back when it was discovered. The rocks only scoot around once every few years, apparently, but there are a lot of rocks and it looks like they all have trails.
Well, Ubuntu releases are only 6 months apart. I'd probably be annoyed if the upgrade was a major change to my workflow. Apple's release cycle seems to be striking a happy medium between "large enough to be worth upgrading" and "small enough not to hurt productivity after the upgrade".
Of course, as upgrading becomes cheaper and less of a hassle on that scale, the ideal upgrade cycle becomes shorter. For something as disruptive as Vista you might as well wait until you need a new computer; for a Linux distro where dist-upgrade is free, automated and all online, frequent small upgrades are fine.
(NB: A more accurate comparison for Ubuntu is between Gutsy and Hoary Hedgehog, which was released the same month as Tiger. The difference: In 2005 every Linux still required geek-fu; today it's on Dells and in Wal-Mart.)