Copper can exceed 56k obviously. Phone lines, as in, a copper pair WITH the telco equipment at the end that imposes a limit, can't exceed 56k. The reason people bring it up is to demonstrate how hard limits exist.
If it was simply a matter of encoding, there would be modems faster than 56k. But there aren't. No, DSL doesn't count, because it doesn't manage to push more through that bottleneck, it simply routes around it entirely.
If you skip the telco stuff and just use the copper you can go faster. But there's still a limit to how much faster.
There are two different things here: The limit of the line and the limit of the receiver at the end of it.
The limit of the receiver in an analog line is 56k. You can't dial a phone number on an analog line and then establish a connection at ADSL speeds from one end to the other. It's like this: ("=" is a fat pipe, "-" is a slow one)
The phone line might be able to handle 10mbps fine, but the DS0 you get inside the telco has a hard 64kbps limit (of which you get to use 56k) and no encoding technology will change that.
The reason ADSL works is because it's not going through that bottleneck:
The telco samples 8 bits at 8000 Hz, so there are frequencies that won't get through it, ever. ADSL works by sending frequencies the telco won't transmit through the phone line, but the DSLAM can use them. Notice how modems haven't budged an inch since they reached 56k. There's simply nothing left to squeeze out.
Your phone line also has a very definite physical limit, which is why ADSL performance depends on the kind of line and its length, and the DSLAM is probably located at some junction near your house. This is the reason why people are starting to get fiber at their house. It's also precisely what the FCC is talking about here -- the medium itself has a limit and no encoding is going to change that. Better encodings simply get closer to the ultimate physical limit, and modern encodings are pretty much perfect already.
Phone lines have a total bandwidth of 64k, of which something speaking through an analog line can only get 56k, with the rest being used for signalling data. There's no way to go any higher. Think of trying to play 24 bit, 96KHz music into a system that only records 8 bit at 11KHz. No matter what you put into that line, you're not getting more quality out of it.
So how does ADSL do it? By bypassing the phone infrastructure entirely. The limit isn't in the line itself, it's in the endpoint. ADSL sends a signal through the line that gets received by special hardware sitting before the telco phone equipment which handles a much higher frequency range.
It's just the Web serving up text and images like the old days, but because of the unusual source (physical media, yikes!) it requires some special UI elements to read conveniently. Sure, they could have just given you an HTML page with an image from the book, but then your search terms wouldn't be highlighted, making it easier to find what you were looking for, nor would you have the same kinds of control over page layout and pagination.
But all that can be done server-side. This discussion is about JS, and what you pointed at can be done by sending plain HTML with nothing else to the browser.
Well, that's always going to be a problem unless you have all umteen terabytes of data on your local system. You're not describing the difference between a native app and a Web app, you're describing the difference between local and remote storage (keep in mind that Web apps now have the capability to take advantage of local storage for caching or even full datasets where that makes sense, so it's not even a fair distinction in many cases).
It doesn't take terabytes. It may take terabytes for Google because they serve it as an image, but the information can be encoded in a much more compact manner.
The full set of maps for the entire planet available for both GPS units I have fits in 4GB or so.
And yes, browser can cache images, but none I know has anything like "Give google maps 4GB", and the default limit is way too small. Even if that was fixed, the browser's cache is stationary, and I can't for instance download the data for New York on my computer and copy it to my phone.
I think that's actually not true. I believe that Google Maps does try to do some predictive downloading if it has a chance, and may cache some relatively small images like the map of the globe, even when you don't need them.
It may be doing something, but probably not enough. I understand it's a hard problem. Most people don't have enough bandwidth to download images for all sides, plus higher and lower zoom levels fast enough to keep up with anything the user might do.
How would that change if you used a non-Web mapping program with as much image and vector data as Google Maps?
In such cases, the concern isn't to be able to zoom in until you see ants on the sidewalk, but to get any data at all. So far I've not really had any problems with the amount of mapping data my phone contains.
And if that's all you want, you're good to go. I prefer having much more data at my fingertips. Try downloading satellite, vector map and terrain data for the entire world at several scales onto your phone and let me know how that works out.
But it doesn't need to be in several scales. Vector maps are inherently scalable. And a modern phone isn't limited to what a browser can do, so it doesn't need to do things like having everything as an image. That leaves satellite data, which while very nice is highly optional, and will probably eventually fit on a phone as well.
My phone can actually download satellite data if it has a connection, as well as the map for anything it doesn't have on the SD card, but if I happen to be stuck somewhere without an usable 3G connection, it'll still be able to find the way to where I'm going.
There are times that works well (Wikipedia comes to mind), and other times when it works very, very poorly (any image gallery where the user wants to look at many or every image at full size). There are always problem domains to consider and a good UI does so.
Actually what I'd really like is a gallery tag, which the browser could render in whatever way the user prefers
I had a 3.5" disk running at 65C in a cramped mini-ITX case. The case was almost entirely filled with hardware and cabling, and only had two 40mm fans for the whole thing. The disk was behaving rather oddly, which I didn't find surprising at all.
In my experience, drives in a badly cooled desktop can quite easily reach 50C. 7200 RPM drives also manage to get impressively hot when used outside the case (I've ocassionally done this to copy data over and such)
People who like pointing to the Google study completely ignore that it's data that comes from servers in a datacenter, and not a set of normal users, some of which have horrible cases with no airflow, and an ambient temperature of 35C.
Notice how going from 1066 to 2000 ( 87% faster memory ) gains less than 5% in framerate in HL2.
Assuming that scaling holds in general, the 5% hit of ECC will slow you down by about 0.25% total. That's well within the noise inherent in a benchmark.
Even in the case of Far Cry, which sees the most benefit from faster RAM, the hit from ECC would still be hard to notice at ~2%.
At 3,751 errors per DIMM/year it means that a system with 2 sticks (very common for dual channel) is getting 20 bits flipped per day. The question then is how long will it take for that to screw up something important.
Since a modern machine has plenty RAM for disk cache, and in many workloads most memory would be dedicated to that, this would easily mean that every day some software operates on data that's not exactly what was on disk, and if you write any significant amount of data back, it's quite possible you're writing the wrong thing as well.
Since the data on disk persists, this means that your data is getting constantly more screwed up.
ECC is slower by something like 1%, which is completely unnoticeable since RAM contributes relatively little to the overall system performance. 2x faster RAM won't make things run twice as fast, because normally CPU caches get a > 90% hit ratio. Otherwise things would be incredibly slow, as the fastest RAM still is horribly slow and has a horrible latency compared to the cache.
* Temperature plays little role in errors - just as Google found with disk drives - so heroic cooling isn'tt necessary.
Talk about a misunderstanding.
First, the paper on hard drives did show that temperature was important. It did show though that too cold is worse than too hot. Also, the data wasn't perfect. Google doesn't have a whole lot of drives running at strange temperatures, since they're a datacenter. A consumer though, might well run a drive at 60C in a badly cooled desktop or laptop, and there's not a single datapoint on Google's graph for that.
In my experience, a drive cooled by a case intake fan runs at about 35c, which comes up as just perfect on google's graph.
The memory paper finds an even bigger effect:
Figure 7 (left) shows that for all platforms higher temper- atures are correlated with higher correctable error rates. In fact, for most platforms the correctable error rate increases by a factor of 3 or more when moving from the lowest to the highest temperature decile (corresponding to an increase in temperature by around 20C for Platforms B, C and D and an increase by slightly more than 10C for Platform A ).
I believe 3x more errors is pretty damn significant, unless you want to adhere to the idea of that a very rare event happening 3 times as often is still very rare, relatively speaking.
But "a mean of 3,751 correctable errors per DIMM per year." sounds rather big to me. Sure, it's a tiny part of 4GB of RAM. But a single bit wrong in exactly the right place could result in things like very unpleasant disk corruption, and most FSes won't like that because they're not designed to compensate for random disk corruption (yeah, I know about ZFS and its checksums, but not everybody runs it)
@months = split(//, "January February March April May June July August September October November December");
As well. Though I find the qw idiom more natural for the particular task. For me it's deeply ingrained that split() is something you do at runtime, to a variable that may have a different content every time. qw is a compile time operation. To me, "@months = qw (...)" and "@months = (..)" are Perl versions of the C array initializer "char *months[] = {... }", while split implies a mess with malloc and strtok, and which should be avoided for static data.
Python's full grammar specification fits on two pages of A4.
That's good to know, it'll make things easier when I finally find a reason to bother learning it. Not trying to troll here, I know Perl, it does everything I need doing at the time. Learning another language to do the same thing except in a prettier and maybe slower way seems wasteful with other more interesting things to do.
Douglas' funniest bits were sneaked into very minor bits of exposition, not critical plot points. "The spaceships hung in the air just like bricks don't." The rest of his humor comes from knowing the proper way to deliver his lines, largely requiring at least some exposure to Monty python or other British comedy to know how to read 'Ford, you're turning into a penguin. Stop it.' Read the wrong way the humor is lost.
That would explain why I tried one of his books and found it completely unfunny.
The "The spaceships hung in the air just like bricks don't." stuff comes up as "look, I'm so clever!", which ends up sounding lame. And the monty python bits of course got lost because I hadn't seen any of it at that time yet.
This is the rallying cry of the anti-Web-app crowd. "I liked the good old Internet."
The problem is that the good old Internet kind of sucked.
Depending for what kind of use. If you want to make apps on it, indeed it did. But I don't want apps, so the current one sucks more for me.
Look at the original MapQuest vs. Google Maps. I spent large amounts of time trying to find things on MQ back in the day. When Google Maps came out, it changed the way mapping worked. Dragging the map around to pan alone was worth having to suffer slow (now much better) JavaScript interpreters. Now, of course, MQ uses a Google Maps-like JavaScript UI for that very reason.
Actually I vastly prefer a map implemented as an application.
Google Maps works in an emergency, but it's annoying. Sometimes a square won't load for some weird reason. It never loads the squares beyond the borders fast enough to scroll comfortably. It definitely never loads images for any zoom level other than the one you're at. On a slow connection, it's unberable to use.
Even crappy GPS phone applications are vastly more responsive than google maps. Give me a desktop application that caches the whole map on disk, and I'll never go to maps.google.com again.
On the other hand, as a publisher, I want things like the image-popup you mentioned because it allows me to publish images in a way that maintains my site's flow (e.g. the ability to navigate to the next image in a set, comment on an image, and so on). These features need to be revised, smoothed and made more friendly to the kinds of browsing that people do and the way they expect their browser to behave, I agree, but throwing away the JavaScript UI isn't the way to do that.
You don't really need to use JS to show images. Just make a big, page-wide grid of image thumbnails. A lot easier, and much more comfortable to find things in than by clicking "next" 20 times.
The question is: of those websites, how many of them do their current functions better than if they didn't have javascript?
Slashdot, for instance?
I much prefer the old interface.
This is not a question of whether or not it "can work" without javascript; it's a question of whether or not the user interface, user experience, functionality, etc., is enhanced through javascript.
In my experience, most sites don't enhace anything, they rather make it more annoying.
For instance, various sites with images now do this annoying thing where clicking an image makes a sort of modal window appear in the middle of the page, expand and show the photo. Yeah, fairly cool looking for about 5 seconds. Then it becomes very annoying because the effect wastes time, and it typically breaks the "open in new tab" middle click function, which makes it hard to show the image to somebody else.
I actually changed the place I shop for computer stuff at because of issues like that. The shop I use displays all the products in a category in a plain table, which can be sorted by any column.
The question is, again... is it better (or worse) with javascript/ajax/whatever. If it's better, then why not? If not, then you have a point.
IMO, the functionality can be used well, but rarely is. Pretty much anything that makes something like AJAX the main focus of the site overdoes it and ends up making it horrible to use.
Though I'll admit I don't like the whole concept of web applications in the first place and generally avoid using anything that looks like one.
You pick one if buying for a desktop, and another if buying for a laptop. Then buy based on cost by MB.
SSDs have made this slightly more complex, but you can easily see it with them: The main reason why everybody didn't switch to a SSD yet is that the cost per MB is too high.
Sure it's superflous, but it also makes the card much easier to handle. There's plenty room to grab the card comfortably, or to put it on any surface without worrying too much about it.
But once the bank equipment stops being upgraded, people won't be saying "I wish we still had programmers". They'd be wishing they still had lawyers so they could work out how to get their money back without having to shoot people.
If all programmers disappeared, modern society would slowly freeze in place. There's lots and lots of infrastructure that needs computers to work, and which isn't practical to do by hand. Existing software would remain of course, but new software wouldn't be created. Which would mean that for instance, no new car models would be made, because the assembly line robot's code needs to get tweaked a bit, nobody can do it, and doing the robot's work by hand is ridiculously expensive.
Life without lawyers, hmm. In my life so far I've never had to deal one, and lack of lawyers doesn't mean lack of judges.
PAE is a hack, and applications still get a 2/3 GB limit. A 32 bit application will not be able to malloc 8GB.
Additionally, Windows doesn't support PAE anyway, so you'll only get more than ~3.5GB if you run something else. The 4GB of address space includes things like video RAM, so a card with 1GB of memory will limit you to 3GB. Run SLI and that's 2GB.
I don't think the USB-IF deserves that much blame.
While I appreciate what Palm is trying to do here, USB devices are supposed to identify themselves by the allocated manufacturer number, and it's common in my experience at least to have drivers locate the right device by checking manufacturer and device IDs.
Manufacturers using whatever IDs they like can result in collisions in the namespace, which will result in things like crashing and malfunction sooner or later.
Note also that my mouse uses the Logitech manufacturer ID, though it's a completely standard mouse that works with the standard USB functionality. It doesn't pretend to be made by Apple, or whichever company made the first USB mouse.
Bus 002 Device 005: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse Bus 002 Device 002: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
Re:Great! Another language to learn!
on
Perl 5.11.0 Released
·
· Score: 3, Insightful
I'm sure someone thought it was a brilliant idea to save keystrokes - why type "list.GetRange(0,3)" when you can create syntax using random unused symbols on your keyboard like @states[0..3]? After all, the metric we use to judge programmer productivity is the number of keystrokes they use writing code, not the maintainability of their code.
What random symbols? the 0..3 type of syntax seems to be pretty common outside of Perl as well.
And Perl doesn't have a.GetRange(0,3) type syntax since it's not an OO language originally. OO was grafted on to it later, so a list in Perl is still a list, and not an object with methods.
Oh yeah! And let's pick a totally random set of characters and use it to tell the code syntax parser to change modes! How brilliant! We can just use "qw" to mean "list of strings operator". Sure, why not, nobody would ever write a function called qw on their own, so there will never be a conflict.
Same logic could apply to exactly any other function. Personally I think "print" is a much more logical name for a function a programmer might want to use than "qw" (if your code has functions with names like that, I don't want to deal with it).
As a language construct though, it'd be weird if "qw" had a much longer name, since it's intended to help make things shorter. And it probably stands for "quote words" which seems pretty logical given what it does.
Also, this complaint seems odd in regards to Perl, which has a much cleaner namespace than many other languages, and helps keeping it clean.
And now our code has random text in it which is hard to scan for and isn't surrounded by quotes and doesn't obey the same logic that any other text does.
I don't get this part?
Seriously, consistency helps reduce the burden on a programmer. There is no excuse for a language that attempts to remove readability and consistency for the sake of reducing the number of keystrokes required to type a task. You can only save yourself typing time once, whereas readable code saves you time every day for years.
I agree, though in part only.
Seriously, Perl gives you a choice. If you don't like it, don't use it. I don't use every single construct I can either. Sometimes they help:
my @months = qw( January February March April May June July August September October November December );
Why type all those quotes and commas, which can easily be messed up, leading to a compile failure? It's even more readable this way. Sometimes things like $_ help inside things like map, sometimes they make things more confusing. A good programmer knows when a tool is appropiate.
Sometimes quick and dirty is a good thing. When I make a log parser in 15 minutes to gather some stats for a one time event, it helps being able to take some shortcuts. But those are by no means necessary, and I don't use them when writing bigger things.
With the additional advantage of that it uses a regular expression, so you can split by a much more complex criteria.
The difference is that qw happens at compile time, and split happens at runtime, so it has efficiency advantages. Additionally, qw lets you choose the delimiter. For instance:
@array1 = qw( its whale guts ); @array2 = qw/ its whale (guts)/;
Slashdot Mirror
Er, why is a web browser needed at all to display a selection screen? It's not like they couldn't make a little program to choose one.
This ridiculous shoving of a web browser into places it doesn't belong is starting to get annoying.
Again, no.
Copper can exceed 56k obviously. Phone lines, as in, a copper pair WITH the telco equipment at the end that imposes a limit, can't exceed 56k. The reason people bring it up is to demonstrate how hard limits exist.
If it was simply a matter of encoding, there would be modems faster than 56k. But there aren't. No, DSL doesn't count, because it doesn't manage to push more through that bottleneck, it simply routes around it entirely.
If you skip the telco stuff and just use the copper you can go faster. But there's still a limit to how much faster.
Er, no.
There are two different things here: The limit of the line and the limit of the receiver at the end of it.
The limit of the receiver in an analog line is 56k. You can't dial a phone number on an analog line and then establish a connection at ADSL speeds from one end to the other. It's like this: ("=" is a fat pipe, "-" is a slow one)
The phone line might be able to handle 10mbps fine, but the DS0 you get inside the telco has a hard 64kbps limit (of which you get to use 56k) and no encoding technology will change that.
The reason ADSL works is because it's not going through that bottleneck:
The telco samples 8 bits at 8000 Hz, so there are frequencies that won't get through it, ever. ADSL works by sending frequencies the telco won't transmit through the phone line, but the DSLAM can use them. Notice how modems haven't budged an inch since they reached 56k. There's simply nothing left to squeeze out.
Your phone line also has a very definite physical limit, which is why ADSL performance depends on the kind of line and its length, and the DSLAM is probably located at some junction near your house. This is the reason why people are starting to get fiber at their house. It's also precisely what the FCC is talking about here -- the medium itself has a limit and no encoding is going to change that. Better encodings simply get closer to the ultimate physical limit, and modern encodings are pretty much perfect already.
ADSL bypasses the problem entirely.
Phone lines have a total bandwidth of 64k, of which something speaking through an analog line can only get 56k, with the rest being used for signalling data. There's no way to go any higher. Think of trying to play 24 bit, 96KHz music into a system that only records 8 bit at 11KHz. No matter what you put into that line, you're not getting more quality out of it.
So how does ADSL do it? By bypassing the phone infrastructure entirely. The limit isn't in the line itself, it's in the endpoint. ADSL sends a signal through the line that gets received by special hardware sitting before the telco phone equipment which handles a much higher frequency range.
But all that can be done server-side. This discussion is about JS, and what you pointed at can be done by sending plain HTML with nothing else to the browser.
It doesn't take terabytes. It may take terabytes for Google because they serve it as an image, but the information can be encoded in a much more compact manner.
The full set of maps for the entire planet available for both GPS units I have fits in 4GB or so.
And yes, browser can cache images, but none I know has anything like "Give google maps 4GB", and the default limit is way too small. Even if that was fixed, the browser's cache is stationary, and I can't for instance download the data for New York on my computer and copy it to my phone.
It may be doing something, but probably not enough. I understand it's a hard problem. Most people don't have enough bandwidth to download images for all sides, plus higher and lower zoom levels fast enough to keep up with anything the user might do.
In such cases, the concern isn't to be able to zoom in until you see ants on the sidewalk, but to get any data at all. So far I've not really had any problems with the amount of mapping data my phone contains.
But it doesn't need to be in several scales. Vector maps are inherently scalable. And a modern phone isn't limited to what a browser can do, so it doesn't need to do things like having everything as an image. That leaves satellite data, which while very nice is highly optional, and will probably eventually fit on a phone as well.
My phone can actually download satellite data if it has a connection, as well as the map for anything it doesn't have on the SD card, but if I happen to be stuck somewhere without an usable 3G connection, it'll still be able to find the way to where I'm going.
Actually what I'd really like is a gallery tag, which the browser could render in whatever way the user prefers
I had a 3.5" disk running at 65C in a cramped mini-ITX case. The case was almost entirely filled with hardware and cabling, and only had two 40mm fans for the whole thing. The disk was behaving rather oddly, which I didn't find surprising at all.
In my experience, drives in a badly cooled desktop can quite easily reach 50C. 7200 RPM drives also manage to get impressively hot when used outside the case (I've ocassionally done this to copy data over and such)
People who like pointing to the Google study completely ignore that it's data that comes from servers in a datacenter, and not a set of normal users, some of which have horrible cases with no airflow, and an ambient temperature of 35C.
It's been a while since I looked, but I remember seeing benchmarks of 1-2%.
Still, here's what I was talking about
Notice how going from 1066 to 2000 ( 87% faster memory ) gains less than 5% in framerate in HL2.
Assuming that scaling holds in general, the 5% hit of ECC will slow you down by about 0.25% total. That's well within the noise inherent in a benchmark.
Even in the case of Far Cry, which sees the most benefit from faster RAM, the hit from ECC would still be hard to notice at ~2%.
At 3,751 errors per DIMM/year it means that a system with 2 sticks (very common for dual channel) is getting 20 bits flipped per day. The question then is how long will it take for that to screw up something important.
Since a modern machine has plenty RAM for disk cache, and in many workloads most memory would be dedicated to that, this would easily mean that every day some software operates on data that's not exactly what was on disk, and if you write any significant amount of data back, it's quite possible you're writing the wrong thing as well.
Since the data on disk persists, this means that your data is getting constantly more screwed up.
ECC is slower by something like 1%, which is completely unnoticeable since RAM contributes relatively little to the overall system performance. 2x faster RAM won't make things run twice as fast, because normally CPU caches get a > 90% hit ratio. Otherwise things would be incredibly slow, as the fastest RAM still is horribly slow and has a horrible latency compared to the cache.
Talk about a misunderstanding.
First, the paper on hard drives did show that temperature was important. It did show though that too cold is worse than too hot. Also, the data wasn't perfect. Google doesn't have a whole lot of drives running at strange temperatures, since they're a datacenter. A consumer though, might well run a drive at 60C in a badly cooled desktop or laptop, and there's not a single datapoint on Google's graph for that.
In my experience, a drive cooled by a case intake fan runs at about 35c, which comes up as just perfect on google's graph.
The memory paper finds an even bigger effect:
I believe 3x more errors is pretty damn significant, unless you want to adhere to the idea of that a very rare event happening 3 times as often is still very rare, relatively speaking.
But "a mean of 3,751 correctable errors per DIMM per year." sounds rather big to me. Sure, it's a tiny part of 4GB of RAM. But a single bit wrong in exactly the right place could result in things like very unpleasant disk corruption, and most FSes won't like that because they're not designed to compensate for random disk corruption (yeah, I know about ZFS and its checksums, but not everybody runs it)
You can do:
As well. Though I find the qw idiom more natural for the particular task. For me it's deeply ingrained that split() is something you do at runtime, to a variable that may have a different content every time. qw is a compile time operation. To me, "@months = qw (...)" and "@months = (..)" are Perl versions of the C array initializer "char *months[] = { ... }", while split implies a mess with malloc and strtok, and which should be avoided for static data.
That's good to know, it'll make things easier when I finally find a reason to bother learning it. Not trying to troll here, I know Perl, it does everything I need doing at the time. Learning another language to do the same thing except in a prettier and maybe slower way seems wasteful with other more interesting things to do.
That would explain why I tried one of his books and found it completely unfunny.
The "The spaceships hung in the air just like bricks don't." stuff comes up as "look, I'm so clever!", which ends up sounding lame. And the monty python bits of course got lost because I hadn't seen any of it at that time yet.
Depending for what kind of use. If you want to make apps on it, indeed it did. But I don't want apps, so the current one sucks more for me.
Actually I vastly prefer a map implemented as an application.
Google Maps works in an emergency, but it's annoying. Sometimes a square won't load for some weird reason. It never loads the squares beyond the borders fast enough to scroll comfortably. It definitely never loads images for any zoom level other than the one you're at. On a slow connection, it's unberable to use.
Even crappy GPS phone applications are vastly more responsive than google maps. Give me a desktop application that caches the whole map on disk, and I'll never go to maps.google.com again.
You don't really need to use JS to show images. Just make a big, page-wide grid of image thumbnails. A lot easier, and much more comfortable to find things in than by clicking "next" 20 times.
Slashdot, for instance?
I much prefer the old interface.
In my experience, most sites don't enhace anything, they rather make it more annoying.
For instance, various sites with images now do this annoying thing where clicking an image makes a sort of modal window appear in the middle of the page, expand and show the photo. Yeah, fairly cool looking for about 5 seconds. Then it becomes very annoying because the effect wastes time, and it typically breaks the "open in new tab" middle click function, which makes it hard to show the image to somebody else.
I actually changed the place I shop for computer stuff at because of issues like that. The shop I use displays all the products in a category in a plain table, which can be sorted by any column.
IMO, the functionality can be used well, but rarely is. Pretty much anything that makes something like AJAX the main focus of the site overdoes it and ends up making it horrible to use.
Though I'll admit I don't like the whole concept of web applications in the first place and generally avoid using anything that looks like one.
Threads won't help. Threads share address space.
Now different processes would do. But depending on the task that may complicate things quite a bit. Not all datasets can be split into chunks easily.
Eh? Hard drives come in 2 normal standard sizes.
You pick one if buying for a desktop, and another if buying for a laptop. Then buy based on cost by MB.
SSDs have made this slightly more complex, but you can easily see it with them: The main reason why everybody didn't switch to a SSD yet is that the cost per MB is too high.
Actually, I really like it.
Sure it's superflous, but it also makes the card much easier to handle. There's plenty room to grab the card comfortably, or to put it on any surface without worrying too much about it.
Yep, we should completely ignore it and let the lie stand unchallenged, so that a bad piece of legislation can become a law for the wrong reason.
I consider such shenanigans to automatically mean it doesn't fit my needs. If not right now, then later.
Or they could take the even easier way, and stop being dicks about it.
Seriously, this kind of thing is why I don't own anything Apple makes, and don't plan to.
If all programmers disappeared, modern society would slowly freeze in place. There's lots and lots of infrastructure that needs computers to work, and which isn't practical to do by hand. Existing software would remain of course, but new software wouldn't be created. Which would mean that for instance, no new car models would be made, because the assembly line robot's code needs to get tweaked a bit, nobody can do it, and doing the robot's work by hand is ridiculously expensive.
Life without lawyers, hmm. In my life so far I've never had to deal one, and lack of lawyers doesn't mean lack of judges.
Handle more than 4GB ram *well*.
PAE is a hack, and applications still get a 2/3 GB limit. A 32 bit application will not be able to malloc 8GB.
Additionally, Windows doesn't support PAE anyway, so you'll only get more than ~3.5GB if you run something else. The 4GB of address space includes things like video RAM, so a card with 1GB of memory will limit you to 3GB. Run SLI and that's 2GB.
I don't think the USB-IF deserves that much blame.
While I appreciate what Palm is trying to do here, USB devices are supposed to identify themselves by the allocated manufacturer number, and it's common in my experience at least to have drivers locate the right device by checking manufacturer and device IDs.
Manufacturers using whatever IDs they like can result in collisions in the namespace, which will result in things like crashing and malfunction sooner or later.
Note also that my mouse uses the Logitech manufacturer ID, though it's a completely standard mouse that works with the standard USB functionality. It doesn't pretend to be made by Apple, or whichever company made the first USB mouse.
What random symbols? the 0..3 type of syntax seems to be pretty common outside of Perl as well.
And Perl doesn't have a .GetRange(0,3) type syntax since it's not an OO language originally. OO was grafted on to it later, so a list in Perl is still a list, and not an object with methods.
Same logic could apply to exactly any other function. Personally I think "print" is a much more logical name for a function a programmer might want to use than "qw" (if your code has functions with names like that, I don't want to deal with it).
As a language construct though, it'd be weird if "qw" had a much longer name, since it's intended to help make things shorter. And it probably stands for "quote words" which seems pretty logical given what it does.
Also, this complaint seems odd in regards to Perl, which has a much cleaner namespace than many other languages, and helps keeping it clean.
I don't get this part?
I agree, though in part only.
Seriously, Perl gives you a choice. If you don't like it, don't use it. I don't use every single construct I can either. Sometimes they help:
Why type all those quotes and commas, which can easily be messed up, leading to a compile failure? It's even more readable this way. Sometimes things like $_ help inside things like map, sometimes they make things more confusing. A good programmer knows when a tool is appropiate.
Sometimes quick and dirty is a good thing. When I make a log parser in 15 minutes to gather some stats for a one time event, it helps being able to take some shortcuts. But those are by no means necessary, and I don't use them when writing bigger things.
Perl has that too.
With the additional advantage of that it uses a regular expression, so you can split by a much more complex criteria.
The difference is that qw happens at compile time, and split happens at runtime, so it has efficiency advantages. Additionally, qw lets you choose the delimiter. For instance: