I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
> Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing.
I'd like to hear of a real use case for namespaces that existing conventions don't already solve.
Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>".
Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing:
module MyGroup
include Module1
include Module2
...
end
In other words, wrapping them doesn't remove your ability to use short non-namespaced names.
Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace
For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby:
def wrap_load(path) = class_eval(File.read(path), path)
module Test
# some_file.rb will act as-if defined within Test
wrap_load("./some_file.rb")
end
You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies.
Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.
Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new.
And why would you bother doing that when it would be a breaking change?
On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
Using Ruby modules to namespace things is certainly possible, but is very often cumbersome. Modules also "hardcode" a namespace: that is, if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere -- or, in other words, namespacing is controlled by library author, not user. The proposed feature shifts that control to library user.
> if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere
It will be identified as such by e.g. the default `inspect`, but nothing stops you from `include`-ing MyModule into another module or class, or even the global scope so that you can reference MyClass without MyModule.
I recently read almost the whole book in a week or so. It's excellent and I feel like I can write in D pretty well after reading it. Too bad that I most likely won't be writing in D, but, at least, I'm confident I can come back to it anytime and be up to speed if I ever need to. This book should be the goto for anyone who wishes to quickly learn the language.
I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe".
Examples:
* Python preferred over Ruby
* TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS)
* Go is preferred over Crystal and D.
While Python, TypeScript and Go are quite alright, there is no doubt in my mind that their alternatives are absolutely superior as languages. Yes, in case of Dart, Crystal and D the ecosystem doesn't have the abundance of well-tested libraries, but as languages they are simply better. The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
Dart is much worse than TypeScript. The over-reliance on codegen for the most simple things (e.g. https://pub.dev/packages/freezed#primary-constructors), the lack of expressiveness of the type system (it only got sum types very recently), and a lot of other little annoyances are ever present when having to write Dart.
Languages do not matter as much as you think. Ecosystems are everything. Twice in my life I started companies (the first one took all my life savings) and in both cases the right call was what you called an "inferior language".
I actually liked D very much, and WB had been a personal hero of mine when I was in college. But I am not betting my career on an ecosystem built around by a single brilliant guy. For high-stakes projects, a wise decision is building on a platform with several deep-pocketed backers.
And for toy/personal projects... do you even need a language anymore? Just ask your favorite LLM to generate you an executable which does what you want (partially joking here).
D's ImportC feature makes it super easy to access C libraries from D code. That means D fits right in with a C ecosystem, as it's no longer necessary to attempt to translate the .h files into D.
It's not perfect, as some people cannot resist using the C preprocessor for some bizarre constructions.
I used to write those bizarre things myself in C, and was proud of my work. But one day I decided to remove them all, and the code was better.
One area where Go, C# and Rust beat D is packages in a few different ways.
For C# Microsoft eventually embraced NuGet their package manager, and used it to put core packages that don't need to be fully available OOTB but can then benefit from frequent updates on a per project basis as opposed to updating the entire language runtime.
For Go it was the out of the box packages, like if I want to make a website, I can pull in net/http and their templating packages that come out of the box with Go, maybe a reasonably simple core maintainer package or packages that go into Dub would be a strong selling point. Right now Vibe.d is the only option for web dev, but there's no reason a much simpler web server couldn't exist.
For Rust, I just really love Cargo, I think its one of the nicest package managers I've ever used.
The other thing that would really help D is if something significant is built around D, whether it be a framework (like what Rails did for Ruby) or some major application that needs D to function at its core and is used by many, this could be a groundbreaking modern IDE, or anything really, a database that uses the best bits and pieces of D to scale, or even a really rich cross-platform GUI stack (my kingdom for std.gui to be a thing in D, and reasonably exhaustive).
I wish I had unlimited time and money, I would invest it in D. Alas, I'm not a language maintainer, just a guy who loves really good tools.
It seems like the parent was trying to paint a situation of you being a bottleneck to success. It seems a bit Schrödinger's BFDL though.. is Linus a bottleneck to the most used server operating system? Did Guido hold back Python? The existence of the GDC and LDC compilers torpedoes toolchain concerns.. I'd be more worried about Java or Golang suffering from some eventual corporate buffoonery.
To the parent's point of startups, betting the farm on something like a particular language out of some sense of superiority might mean you are not focusing on the right problems. But if the founders happen to know a less widely used tool it doesn't seem inappropriate either. The type of employee that can drive a startup or a big tech project forward is not going to be thwarted by a language, and they might find something new to learn fun.
D can do C++ interop when the C++ code is "C with classes" style. Some templates are supported. But then things get so complicated with C++ that it's impractical to go further.
... and the job of a programmer will be to explain, in as precise terms as possible, what they need the executable to do. (Reminds me of the idea of programming based on a natural language.)
What pains me in Python adoption, beyond its use as Perl replacement, is that we have so much better dynamic languages with advanced JIT implementations, but have to reach out writing extensions in native languages instead.
At least Python as DSL for GPU JIT compilers is a thing now.
Yes, I know about PyPy in the corner looking for attention.
> we have so much better dynamic languages with advanced JIT implementations
What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
Smalltalk, Self, whose research lead to Hotspot and V8, Common Lisp.
And the usual, in Python everything is dynamic, well it is even more so in an image based live coding environment, where any break into the debugger, with code changes and resume execution can come back to a complete different world.
Additionally there are features like Smalltalk become: message, where two objects can change places everywhere they are used in the image, and current execution.
Clojure could never really be a thing since it ignores the most important rule: fast startup. Because of this, and for no other reason, Clojure will always be an "also ran". It's not about competency of the people working on it. It's a solvable problem the community doesn't acknowledge exists, unless you press them on it, in which case they think "graal" and "babashka" is a valid response, and you're back to square 1.
You missed my remark about PyPy feeling abandoned on the corner, well the same applies to GraalPy.
The Ruby JITs I mentioned are used in production.
While other dynamic language comunities embrace their JITs, in Python world, outside using it as a DSL for GPGPU JITs, it is pretty much let's just keep using CPythion with C and C++ extensions. Adding a JIT to CPython only became a thing after Facebook and Microsoft decided to push for its development.
The superior languages on your list just reflect your personal preferences. There are not perfect languages, just appropriate languages for given application.
It's quite subjective what you consider to be better. Is Ruby better than Python? Maybe so, but Ruby only ever had one killer app that is Rails while Python has a vast ecosystem. Is Crystal better than Go? Maybe so, but Go ist just so much more mature (plus the ecosystem argument).
Regarding ruby and python I thought the 2 were in the same league, esp compared to perl. Over 20 years ago I evaluated both and went ruby because of the more consistent api and of course pythons forced whitespace is an easy tie breaker against it. At this point I'm not to pleased that many younger programmers that python as some sort of default and tend to end up writing far too fancy code in it when it ends up being the wrong tool.
Its really calming that Haxe is not moving as fast as the JS/TS ecosystem. You upgrade once every 3-4 years. Everything just usually "works"
We use Haxe for PHP and its really a secret hidden superpower, im amazed people dont know about / use.
Its mostly marketing, i guess. But i wish more devs tried it as an alternative to PHP or TypeScript, as the language is WAY better in almost every way.
yeah, I know it's alive :) but I was hoping it would be one of the standard recommendations for javascript devs to reach for when they wanted a better type system. (I was also sad that it never developed a good option for desktop apps, the language itself was very pleasant to use but the ecosystem seemed very focused on game dev the couple of times I tried it)
... Perhaps what you're describing is having a niche opinion. If you had some opinions, like a preference for "Everything must be done in as many ways as possible with funky characters" or "I hate indentation", it would certainly seem that the world is against you. But, perhaps, you just really smart and can remember the intention of all the complicated code you wrote a year ago, so you don't even need to write comments, and thats great. However, being special does not mean that some technolgoy is objectively inferior, unless you can actually come up with a provably objective metric.
Overall, the technology that is there, solving most of the problems for most of the cases is the technology that is superior, by the law of the universe, not the other way around.
I don't agree with any of your examples, but I have my own, like Pascal is a better language than C, by many metrics. I can also accept that C, is what people who invented unix, also invented. And that makes Pascal inferior to C, now, as choice for any project that requires that you hire embedded software developers. That's what the universe decided.
> "Everything must be done in as many ways as possible with funky characters"
Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases.
I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (which is pretty often nowadays, due to Python's dominance in ML ).
I can give many examples as to why, but here's a quick toy example to show off the difference in philosophy between Ruby and Python. You have a list of numbers, you want to keep only odd numbers, sort them, and convert them to a string where each number is separated by comma. Here's the Ruby code:
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = [x for x in xs if x % 2 != 0]
ys.sort()
ys = ", ".join(str(y) for y in ys)
Or alternatively in a single line (but in more complex cases this gets extremely unwieldy since, unlike Ruby, Python forces you to nest these, so you can't write nice pipelines that read top-to-bottom and left-to-right):
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = ", ".join(str(y) for y in sorted(x for x in xs if x % 2 != 0))
And this matches my experience pretty well. Things I can do in Ruby in one line usually take two or three lines in Python, are more awkward to write and are less readable.
To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand. Is `.filter` a method or a property of `xs`? Is `{ |x| x.odd? }` an argument to a method or just a statement that comes after `xs.filter`? If it is passed to `.filter`, why does it not have parentheses around it but the `", "` passed to `join` does?
This all makes sense to a person who knows the language a lot, but wrinkles the brain of a newcomer. Too many concepts to juggle in order to understand. On the other hand, the Python one reads quite easily, even if you may have to go right to left.
Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
Those both seem a little bit more consistent than the Ruby example, however. To understand the JS example for example, you only need know that to call a method on an object, you do `object.method(arguments)`, and this is chained in a straightforward manner, with methods called on the returned values left to right. Ditto for the Haskell example. Maybe the Ruby one does the same thing, but even in this extremely simple example, we still have two different ways of doing the same thing.
For Python, you don't really have to use list comprehensions in the place of multiple for loops, you can sacrifice the brevity afforded to write the same thing in a more easily understandable fashion.
> ... confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
I get that this is just a rhetorical question to make a point about newcomers, and I do agree it's not immediately obvious, but for the record: you can imagine any "if"s and "for"s in a list comprehension are nested statements in the same order. So, for example, this:
l = [
y.foo()
for x in my_list
if x.blah() > 7
for y in x.ys()
]
Is equivalent to this:
l = []
for x in my_list:
if x.blah() > 7:
for y in x.ys():
l.append(y.foo())
So the least comprehension is basically in left to right order with the one exception of the actual expression to be added to the list (like y.foo() in the example above).
Yeah, I know, I know. But I imagine many people would mentally want to bracket [e for x in xs for y in ys] like [(e for x in xs) for y in ys] and thus conclude that y is the outer loop.
>Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
The order is mentioned right in the docs, for Python 3:
>Note how the order of the for and if statements is the same in both these snippets.
And it is mentioned even more clearly in corresponding section in the Python 2 docs - last I checked, years ago,
Update: IOW, the nested list comprehension syntax is confusing only to newcomers or even experienced devs who are lazy or stupid enough to not read the docs for the language feature they want to use, before using it, IOW, "winging it", whether to try to seem cool or due to peer pressure or other reasons, all of which are stupid ones, even in the short term, because the cost is higher than the benefit in most cases.
The only difficulty in Ruby code is the block notation. Even then, it is very similar to constructs in JavaScript, Go, D and a number of other languages -- the only difference form JS would be that instead of `(x) => ...` you write `{ |x| ... }`.
Questions such as
> why does it not have parentheses around it but the `", "` passed to `join` does?
would be exactly the same for JavaScript, Go or D. Ruby has the best syntax with regards to blocks/lambdas/closures.
I don't know much Ruby outside of a few toy examples I wrote a long time ago. For most languages, there would be parentheses around objects you pass to functions, like `.filter({|x| x.odd? })`. This lends some consistency and makes it easy (for me at least) to understand that an anonymous function is passed to `filter`. Just separating it using spaces feels like Bash, something I find difficult to write anything slightly complicated in.
> To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand.
I don't understand this argument. You are a beginner only for a tiny fraction of your time using a given programming language. Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
> Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
Everyone who actually programs in a language was once a person who didn't know it. Languages which optimize for succinct terseness might be powerful once you master them, but they will never enter mainstream use, which I guess is not necessarily the aim.
Ruby is in the running, so to speak, so of course that means there are thousands of people who agree with you. I'm not one of them. The fact that Ruby did not take of as much as Python did, even though there was all that RnR hype, is a testament to that. I don't think your examples are readable. What is |x| x.odd? ? (question mark pun intended) This is just "cleverness". I, personally, want my programming language to use method to use a keyword like "is" instead of operand?[question mark operator]
Your critique rests heavily on a small part of the language and specificaly the odd? trick. Python has filter available as well, but you did not use it:
ys = sorted(x for x in xs if x % 2)
# vs
ys = sorted(filter(lambda x: x % 2, xs))
ys = ", ".join(str(y) for y in ys)
I find Python a better language in total, more regular and readable, when one-liners are avoided (though "".join() is not my favorite). I do however like shell and gleam style pipelines, a bit more than fluent style.
> The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
The same argument applies to C++. No one is forcing you to create complex nested templates or other difficult features.
Yet many criticisms to the language are in the form: "But it is possible to write very complex code that no one understands!"
Having coffee almost 30 years in c++ I really good tired of the complexity of it. Some of the newer complexity being workarounds for (in retrospect) poor decisions made decades ago. Build system situation never helped, and I still despise cmake. When D came out I was interested but garbage collection immediately turned me off, in my opinion the boost shared pointers (later adopted into the standard) solved and shut the door on memory leaks as a serious issue.
And then the d2 fiasco sort of blew it all up. Doesn't help that the language always felt very heavy to me. Likewise Rust feels heavy and cumbersome itself.
So it ends up that I'm another one of those who feels the itch getting scratched by zig.
That's very one-dimensional. It's usually easy to tell what the code does, but what's hard is to modify or add functionality to it. And this is because of various levels of abstractions that hide how things are interconnected.
Another thing that comes to mind is the level at which one is familiar with a particular style of code organization & a set of abstractions. For example, Rails devs really have absolutely no problem getting up to speed with any given Rails app, but people who don't practice Ruby/Rails as their primary language/framework often complain how complicated and magical it is.
Poor abstractions. Good abstractions make it easier to change things, by decomposing the code into cohesive pieces with low coupling so that you can swap them out and having to think about the surrounding pieces beyond their interfaces. A good interface is small and logical.
Good abstractions make it easy to change the things that will change. Abstractions always make some changes harder and some easier, but good ones make hard the things you wouldn't change anyway.
I wish this was true. You can't even get hired if you're proficient in a language, but don't know framework X. Which is understandable for, say Ruby (I don't know anyone who knows Ruby, but doesn't know Rails), but it's inexcusable for JavaScript. I've been programming JavaScript since like 1997. Sure, I'll pick up React no problem, but I won't be touching it unless I'm paid, because React is a disgrace.
But it's not just these languages. It's every other language pretty much. You want to be hired as Go dev? Better know how to use gRPC and Kafka. Java? Better know Spring. I can go on and on.
Unless someone can vouch for you at the company you're applying to, that's unfortunately the game that job seekers have to play.
> You can't even get hired if you're proficient in a language, but don't know framework X.
You can't even get past the very first screening filter. If job asks for, say, 5 years of experience with React, it doesn't matter if you have experience in any other frameworks but "only" 4yoe with React or less. You won't pass the first filter because 4<5.
Sucks if you don't want to lie.
> I've been programming JavaScript since like 1997. Sure, I'll pick up React no problem, but I won't be touching it unless I'm paid, because React is a disgrace.
At the beginning of the month I had an interview for a role that needed to extract a Node.js project to its own microservice. I have literally done this in production (but not Node.js). I have also migrated another project from NoSQL to SQL (but the project was not Node.js). I have developed microservices currently used in production (from design to Terraform to implementation).
But long story short, I didn't pass the initial interview because I haven't been paid to use Node.js during a recent 5-year job. The interviewer even asked, quoting to the best of my memory (and translating to English), "sorry, but none of this was with Node.js?". They were hyperfocused on Node.js as specific tech.
Previous production experience with Node.js? Experience with JavaScript/TypeScript in general? Doesn't matter.
That was not even worth the benefit of allowing me to pass to the technical interview to let me prove myself. And I wouldn't have even minded a live coding/pair-programming exercise.
It means I still need to work better on how I market myself to non-tech people.
> You want to be hired as Go dev? Better know how to use gRPC and Kafka.
And you better know Kubernetes (for some reason), or enjoy working on cryptocurrency projects.
Honestly, I'm greatly annoyed by recruiters. They don't know a single thing about programming and operate solely on keywords. My personal approach now is to just tell them "I have this much experience, I have lots of open-source code which proves my experience, get me an interview with the actual team if they like my resume". Because in 99% of cases it's not even worth the time for a call with a recruiter.
Btw, in your particular example, I think it's fair to tell them "yes, I have the exact qualifications you're looking for", because they won't be able to check anyway. And certainly not whether you had 4 or 5 years of experience with a particular thing.
I would argue that gRPC and Kafka is "general knowledge" in the sense that these are language-agnostic. In other words there is no requirement "Go language knowledge," but a requirement "gRPC and Kafka knowledge."
It really isn't. It's very much tied to certain stacks, while it's completely uncommon in others stacks, because they're solving the same problems in a different way. I've never touched it in my life. Sure, I can pick it up, but I fail to see how it should be considered common.
I see your point, but I still don't think you can just say "If you want to get a job as a Go developer, you must know gRPC." Even more so for Kafka, I've only heard about it being popular in the Java world. You can't even say "If you want to get a job as a Java developer, you must know Spring." Nowadays, sane Java projects use https://vertx.io, it's just too good. I would argue that Spring is for legacy projects only.
Well, how ironic we're in the same boat, it seems. Only I can't get hired because I'm 40 and have many years of experience and everyone seems to assume I'm either a snowflake or will cost them. Granted, I can only afford remote positions at the moment, but then I'm not asking for a lot of money either and I'm fairly easy going. I sure have my preferences, but they're few. What's really making it all unbearable is this leetcode and multiple-round-interviews are just exhausting and they don't lead anywhere, it seems. Nobody's even looking at your published open-source code (which is what I used to do first when I used to hire people). I don't really know if I'll ever work as a software-engineer ever again. Reduced to a hobby, I suppose.
Reaching 50, what keeps me going is enterprise consulting, I also doubt I would have much luck with product companies.
I also join the tone, if what a position is advising for isn't part of what I have done on the last 5 years, than crickets, regardless if I can prove the experience during the interview, or have used the technology further away than those 5 years.
Funnily enough, at the only coding interview I ever had, they specifically told me they won't ask leetcode questions, and they had me write some very simple React code. I think the companies that do those leetcode-style interviews are mostly just those big ones, where it's HR who decides how to interview. I would suggest looking for companies that are small enough to actually care.
Couldn't download the official Windows 11 from the MS website, no matter which VPN or country or server I tried. They know them all by now. ALL. Ain't hard, of course, since all VPNs are mostly hosted at 4, 5, maybe 6 data-centers which belong to large companies. Which names are known to the ones who either deals with them or simply pays attention.
"Networking for Systems Administrators" by Michael W. Lucas.
In retrospect, should've been called "Networking for programmers". Short. Concise. Examples for all operating systems including Windows. That will get you started. After that, to level-up, any book with good ratings would do. And you will also know which part of the networking stack you want to learn more about, thus, you'd pick the correct book for yourself. But this one is a must have if you're feeling very uncertain about your understanding of networking concepts and how everything glues together.
Wanted to bump this. It's the book I recommend when someone asks, "How can I learn networking".
My next favorite is the Top-Down book everyone above mentions. I like that it starts with loading a web page, instead of bits on a wire. And they have pcap files so you don't even need a lab.
The Stevens book is the standard text for programmers writing network code.
Oh, btw, I've recently stumbled upon a VPN-service -- officially registered in country thousands of miles across the ocean from America, not even in Europe. That VPN was pretending to be about privacy and blablabla. The usual. Even offering static ips and port-forwarding (which is rare) and accepting BTC. But the coolest thing was how easy it was to just see through and know who they were: simple check of its IP and the associated ASN lead directly to this captcha-company name. Not to say that was a surprise - an amusement, more like - at how they put every little tentacle they can afford to use out there, to reach everybody, and especially the ones trying to avoid them.
So you keep it up. Waste the money. Even it's not yours, but taxpayers' money (which isn't unlikely). All in vain. And for what purpose? What goal? Who knows. Does it matter for us to try and guess if it ain't going to work?
Cloudflare is operating a VPN service without using its name? Are you sure it’s not someone else forwarding their traffic through Cloudflare (as common with many v2ray providers)
Pretty sure, because the static ip-addresses were offered only for the servers located in very specific countries and particular locations - namely in the US & Canada. And, "coincidentally", that's were the ip-address of their website was.
In addition, they were very adamant about advertising how a static-ip address would relieve you, the customer, of the pains of captchas and thus be whitelisted.
