What's the problem with paying people for their work? It's gotta be tough for these people to keep coming into work everyday when they're receiving nothing more than a few "Thank You" notes for their work.
I've got no problem with paying for software - in the last week I've spent $100 on registration fees for a couple of different programs I'd been using.
But note that I'd been using those programs - they were either shareware, or I was able to download and use demo versions before I paid. I'm a big fan of "try before you buy".
So I'm certainly not going to pay a fee to download a piece of software, when I have not real experience with it to tell me whether or not it is going to be useful to me.
And I will believe it compiles and RUNS BSD apps with the same ease as everything else when I see it for myself.
One of my coworkers, running the OS/X public beta on an older PowerBook, was able to trivally get Kerberos IV and arla (an open-source AFS client, which requires a kernel module to work) running on his machine. The thing is pretty much pure BSD, under the GUI.
What, are you suggesting that pointers are a rarely used aspect of programming? Pshaw.
Simply saying 'Pshaw' hardly qualifies as a compelling argument. Pointers are only really useful when you're doing hardcore systems programming - which is a small minority of the programming that gets done.
Those who took the class with me are as a whole not afraid of pointers. They understand the difference between a memory location and the contents of that memory. When they get to it, they have little trouble adapting to higher level languages, because they understand how those languages work.
Those who took it later are uncomfortable with pointers. They might not even know what one is-- even enough to explain pass by reference. They have a difficult time moving from C++ or Java to something lower-level, such as C.
So here's my question: What is the relative size of these two groups? Are they roughly the same? Or is the second group (the one that generally has trouble with pointers) larger?
Could it be the case that the difficulty of dealing with pointers and assembly language simply acted to filter out those who didn't have certain talents needed to deal with those things. Which would suggest that the earlier curriculum didn't do a better job of teaching pointers, but really just drove people who could have been effective programmers (except when dealing with certain small and now-a-days rarely-used aspects of programming) out of the field.
For the record: I started with BASIC, and then Pascal in High School courses. After Pascal, I taught myself C and X86 assembly; I don't have any trouble dealing with pointers. But, in my day-to-day work, I almost never find myself needing that ability.
Why re-write math.h or a stack in the STL if you can use one that's written?
To make sure you understand the tools that you are using. And that you can survive in their absence. Somebody has to implement those libraries. What happens if you're on a new platform, and that somebody is you?
This paradigm is intended to decouple payment processing from the rest of the website. There really isn't any incentive to "muck with the details".
Except, of course if you want to avoid this bug...
Actually, it's possible to use those systems and still avoid this bug: When the storefront presents the final 'submit' page to the customer, a hidden field (which will be posted to the CC processing company's server) should be included. This field should contain all of the order's pertinent data (price, etc), encrypted with the storefront's private key. When the CC processor gets the submit request from the user, they use the storefront's public key to decrypt the contents of this hidden field and compare the values it contains with those on the form submitted by the user to ensure that no monkeying has taken place.
What did you expect to do, start at the top? You may be the brightest employee since time began, but are almost useless without some practical experience. This is how to get it.
Making copies and ordering parts is not terribly useful practical experience, and isn't likely to lead to Real Work.
My advice to would-be co-ops: Figure out what skills will make them sit up and take notice, and acquire those skills. When I was a senior in HS checking out various colleges, the head of the CS department at one (the one where I ended up) told me that if I knew C or some other common programming language, I'd have no problem finding a co-op job. So I went home, bought a copy of an inexpensive C compiler, and set about teaching myself the language. The department head proved correct: I easily got a job, and was writing real code (in C) just a few weeks after I started working there.
I have to admit, it also helped that I was a programmer surrounded by hardware engineers who didn't have a lot in the way of programming skills. Basically, I was in many ways a "support" person (i.e. the work I was doing wasn't as core to the organization's business), I was trusted with more responsibility than someone who was doing hardware engineering would be.
I have no problem with someone viewing my code. But as I write it? Over my literal shoulder? It's hard enough to think with phones ringing, loud conversations outside my cube and tech support questions every 10 minutes--I don't also need someone sitting behind me humming and clipping his nails.
If your partner is humming and clipping his nails, he's being a lousy partner. The 'watching' half of the pair is not just sitting there passively; he should be actively participating, keeping track of what has to be done next to keep the rest of the system consistent with the changes you're making now, etc.
You mention trouble with distractions in the office. This is actually one of the values of pair programming that isn't immediately obvious: It's actually a great focuser and shield against distractions. Coworkers who want to pull you into a discussion about last night's must-see-TV are far less likely to try to do so when you're working with a partner. And you're far more likely to be disciplined about ignoring these things, yourself. It's also helped me that I treat pair programming sessions every bit as formally as I do meetings: My partner and I set a time, and come up with an agenda in advance of the actual session.
You guys are all on a hair-trigger with the anti-machoism.
I don't think it qualifies as being in hair-trigger mode to respond strongly to someone who proclaims that "the only programmer I'll allow to watch over my shoulder is a dead programmer". If you want calm, measured responses, you should probably speak in a calm, measured manner yourself.
Second of all, the only programmer I'll allow to watch over my shoulder is a dead programmer. And the only way I'll watch some other dimwitted slowpoke feebly hunt-n-peck a single line is if I am allowed to threaten that person with a gun.
Let's try this again...
Suffice to say that I'm glad I don't work with you. The sort of egocentric, programming-as-heroism you seem to favor is rarely useful on nontrivial problems that require multiple programmers. Usually it's a cover for massive insecurity. If you're confident in the quality of the code you write, you shouldn't have any problem with a partner reviewing it as you write it.
Pair programming is lame, IMHO. 2 people will tend to either wander away from the programming topic, as sitting and watchng programming happen can never be as involving as actually programming. Also, 2 or more people tend to bicker over editor styles, code quirks (comment format and such) that gets overlooked during a code review.
So far I've had really good experiences with pair programming. No bickering over editors, etc. Just lots of good code produced. I think it's important to choose good partners. IMO, the best pair programming partner is someone who you're well aquainted with and respect (and whose respect you desire), but who isn't a particularly close friend. This makes it far more likely that the 2 of you will remain disciplined and focused on the code. But the key thing to remember is that the goal is to produce working code.
Second of all, the only programmer I'll allow to watch over my shoulder is a dead programmer. And the only way I'll watch some other dimwitted slowpoke feebly hunt-n-peck a single line is if I am allowed to threaten that person with a gun.
We're still trying to figure out the best way to build software, unlike most of the mature engineering fields that have had anywhere from 100 to 1000 years of practice.
To some extent I agree with this. However, what I've seen so far is that the biggest obstacle to software quality is management's unwillingness to allow the engineers to take the time to do things right. Interestingly enough, I hear pretty much exactly the same complaint from friends of mine who are in other engineering discipline.
I should also note that you're making a rather different claim than TechnoWeenie did: He claims that the basic foundations of software engineering (i.e. computer science) are much less stable than those of civil engineering (i.e. physics). You, on the other hand, are claiming that the processes we build on top of those foundations are not yet stable.
I agree that a formal education isn't absolutely necessary to be a good engineer. But it certainly doesn't hurt. It's particularly valuable when you're dealing with other engineers (assuming that they're similarly educated), because you'll find that you simply have a much better developed "common language" for communicating with them.
The law as it stands today, and the whole legal tradition of our culture, tells us that information is property.
Nonsense. The legal tradition of our culture tells us that the authors of information have a certain set of rights to specify how and by whom that information may be used. This set of rights has traditionally been far less broad than the set of rights that is implied by the word "property".
I started to respond to this by saying I'd never had any good teachers, but then I started to think a bit harder.
My primary school teachers ranged from forgettable to relentlessly bad.
In secondary school, only one stands out in my memory: Jack Sharpe, my Senior year English Lit teacher. I remember when he told us: "Don't write a thesis paragraph for your essay. If you feel you need to do such a thing to create a good essay, write one and cross it out, and I won't read it." Prior to this, I'd had teachers who taught us to write standardized 5 paragaph (thesis-body-body-body-conclusion) essays, and had a hard time with it. I rarely had well-formed ideas about a work when I sat down to write, so coming up with a specific thesis right from the start was rather difficult for me. So I found his approach quite liberating: It was much easier to get started when I could hold off on specifying a thesis and instead focus on some smaller matter. My essays still had coherent conclusions, but I usually would write the first 2-3 paragraphs before I had a clear idea of what the conclusion would be. I should add that Sharpe also had a lot of enthusiasm for his subject, and showed genuine interest in the interpretations his students would come up with. His class fundamentally changed my attitude towards language/literature classes. I'd previously considered them necessary evils at best. Afterwards, I'd come to feel significant pleasure in the process of analyzing a literary work and writing about my thoughts on it. Despite the fact that I went on to study computer science in college and now work as a programmer, this comfort with writing was by far the most valuable thing I got out of high school.
"Three can keep a secret if two of them are dead." -- Benjamin Franklin
Good point. Even if these organizations do attempt to close ranks, it only takes one employee with access to the reports and willingness to leak them to ensure that outside parties "discover" the same holes that the club members do.
One classic example is a program that draws a bunch of different shapes.
I'm familiar with this example: I've implemented it myself, although the "shapes" were actually 3D objects being raytraced, not drawn. I was using C++, and that language's features made it possible to very cleanly and elegantly express what I wanted. Since I got comfortable with C++, I won't touch C with a 10 foot pole, unless I absolutely must.
But for the sake of discussion, let's modify your code slightly: Take the case statement and wrap it in a procedure named DrawShape, which will be used consistently throughout the rest of your code. Having done this, it's really a matter of
shape.Draw()
vs.
DrawShape(shape);
Now, the second version still has certain disadvantages. Most significantly, you have to manually maintain the DrawShape function yourself, increasing the possibility of bugs (since you might forget to update it, whereas the compiler would never forget to generate vtable entries for a new subclass of some abstract base). This will get even worse when you have multiple programmers creating shape types and needing to maintain a single shared DrawShape function.
Still, this scheme means that all changes to how the shape "type hierarchy" works are isolated from the rest of the program. The rest of your code doesn't have to worry about the specific 'subtype' of shape that it's trying to draw at any given time, and if you want to add a Triangle shape type, you merely have to write DrawTriangle (which you have to do, anyways) and add an entry for it to the DrawShape function.
Again: I think that OO is ultimately an approach to constructing programs that is more-or-less independant of the languages we choose for implementation. Some languages may make it more natural, but few make it impossible.
If you just have a data structure and a bunch of procedures that operate on it, then that's just good old-fashioned procedural
programming.
What is an object if not a data structure with a bunch of procedures (which are called methods, in this context) that operate on it?
How would you implement polymorphism this way?
I don't see polymorphism as a fundamental property of OOP, but rather a (very useful) tool that is enabled by language-level support for OOP.
I agree that language support for OO is quite helpful, but as I see it, the fundamental characteristic of OOP is that the explicit and formal (though perhaps not language-supported) definition of the data entities in the system and of the legal operations on those entities.
If you add the methods to manipulate the structure (via function pointers if you're using C), then you have an object.
What do you think the "window_init", "window_draw", and "window_destroy" functions were? Just because these functions weren't formally defined as methods of the window_t object doesn't mean that they aren't methods. In the programmer's mind, they're methods, and that's what matters, in the end.
computers still have a long long way to go speed-wise. it's as if you're in 1904 saying "why would a car ever need to go faster than 25 miles per hour?"
besides, people will always be drawn to the faster machine, both by internal competitive drive and by marketing pressure.
Let's try applying the automotive analogy to that last sentence of yours: "People will always be drawn to the faster car". Er, no actually: People base their car buying decisions on many factors, and speed is pretty far down the list for most people, because any car you'll buy will be more than capable of going as fast as you actually want to go in 99% of situations.
Sure, cars had a lot of room for increases in speed in 1904, but eventually those increases leveled off. Who's to say that the same thing can't happen to computers? How can you say with confidence that it isn't happening already?
Wouldn't an advanced alien species measures things in meters? Or have they not converted over yet, either?
I know you're joking, but several people have made comments like this, and there seems to be this lurking assumption that the metric system is somehow more "rational" or less arbitrary than other systems.
Why would an alien species use the metric system? A meter is defined as "the distance traveled by light in a vacuum during a period of 1/299,792,458th of a second", and a second, in turn, is defined as "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom".
Now aren't those some weird constants in those definitions? That's because the original definition of the meter and second are actually "one ten-millionth of the distance from the north pole to the equator, along the meridian passing through Paris", and "1/86,400th of a solar day", respectively. The definitions based on physical constants were only made later. To an advanced spacefaring civilization, basing a unit of length some physical attribute of a particular planet is just as silly and provincial as basing it on the physical attribute of a particular person (i.e. the king).
The only non-arbitrary part of the metric system is the factor-of-10 relationship between different units of the same type. And that's still a little arbitrary: A factor of 10 makes sense to us because we use the decimal system, which is something that, in turn, we do because we have 10 fingers. To an alien race that has 16 tentacles, it's a bit inconvenient.
In measurement, what's important is that everyone use the same standard. That is the primary reason to go with metric: most other people already do. The intrinsic qualities of the system are far less important.
The simple fact of the matter is that programmers aren't the only technically comptent people who use computers. The idea that *everyone* should *have* to program all the time to fit into this guy's rather skewed world view is ridiculous!
Where does he actually say this?
Answer: Nowhere.
The goal stated on the philosophy page is to provide a smoother path into programming so that anyone can become a programmer. Not to require everyone to become a programmer.
The fact is, despite enormous amounts of effort that have been put into building user interfaces that will put power and flexibility into the hands of nonprogrammers, these interfaces still provide only a fraction of the power that programmers enjoy. An approach that lowers the barriers to "programmer-hood" may prove to be a more fruitful path to putting real utility into the hands of the common person.
The goal isn't to have the average person writing applications from scratch. The goal is to make it possible for the average person to adjust the functioning of existing applications to better suit their needs, to write small scripts that automate common tasks, etc.
Whether or not this is an attainable goal is another question entirely, but I certainly can't fault the guy for trying.
It seems to me despite your obviously biased viewpoint, that the RBL did what it was designed to do. It forced a company to secure its servers, so they could not be used for spam anymore.
You miss his point. The measure of the RBL's usefulness isn't merely how good it is at punishing spammers, but rather, how good it is at doing so, while avoiding punishing non-spammers. If the RBL frequently lists addresses unjustly, eventually people will lose respect for it and stop using it.
I mean, I could stop all spam by unplugging my machine from the network. Somehow this strikes me as a less-than-ideal solution, though.
I am an American and I lived in France for two years. I never encountered a French citizen hostile to me because of my nationality (except for one communist guy in Toulouse; he was just fundamentally anti-American, but otherwise very cool).
I've visited a couple of times (Paris only), and had similar experiences. However, I didn't find that speaking French well was a necessity - mine is limited to "oui", "non", "merci", and "parle vous anglais?", and never encountered anything I would call rudeness. I think the key was that I didn't assume anybody spoke American - I prefaced pretty much every conversation with that last phrase. For that matter, don't assume that too much of anything will be like it is in the US, and you'll probably get along okay.
And Paris is indeed beautiful. I'm toying with the idea of taking a few classes in french so that I could maybe live and work there for a few years.
Slashdot Mirror
I've got no problem with paying for software - in the last week I've spent $100 on registration fees for a couple of different programs I'd been using.
But note that I'd been using those programs - they were either shareware, or I was able to download and use demo versions before I paid. I'm a big fan of "try before you buy".
So I'm certainly not going to pay a fee to download a piece of software, when I have not real experience with it to tell me whether or not it is going to be useful to me.
One of my coworkers, running the OS/X public beta on an older PowerBook, was able to trivally get Kerberos IV and arla (an open-source AFS client, which requires a kernel module to work) running on his machine. The thing is pretty much pure BSD, under the GUI.
Simply saying 'Pshaw' hardly qualifies as a compelling argument. Pointers are only really useful when you're doing hardcore systems programming - which is a small minority of the programming that gets done.
Those who took the class with me are as a whole not afraid of pointers. They understand the difference between a memory location and the contents of that memory. When they get to it, they have little trouble adapting to higher level languages, because they understand how those languages work.
Those who took it later are uncomfortable with pointers. They might not even know what one is-- even enough to explain pass by reference. They have a difficult time moving from C++ or Java to something lower-level, such as C.
So here's my question: What is the relative size of these two groups? Are they roughly the same? Or is the second group (the one that generally has trouble with pointers) larger?
Could it be the case that the difficulty of dealing with pointers and assembly language simply acted to filter out those who didn't have certain talents needed to deal with those things. Which would suggest that the earlier curriculum didn't do a better job of teaching pointers, but really just drove people who could have been effective programmers (except when dealing with certain small and now-a-days rarely-used aspects of programming) out of the field.
For the record: I started with BASIC, and then Pascal in High School courses. After Pascal, I taught myself C and X86 assembly; I don't have any trouble dealing with pointers. But, in my day-to-day work, I almost never find myself needing that ability.
Assuming you mean FreeBSD, just log in as root, and execute "cd /usr/ports/lang/python ; make ; make install".
If you don't mean FreeBSD, well: the CPython interpreter is fairly portable, IIRC, and should build under most unixes with little trouble.
To make sure you understand the tools that you are using. And that you can survive in their absence. Somebody has to implement those libraries. What happens if you're on a new platform, and that somebody is you?
This paradigm is intended to decouple payment processing from the rest of the website. There really isn't any incentive to "muck with the details".
Except, of course if you want to avoid this bug...
Actually, it's possible to use those systems and still avoid this bug: When the storefront presents the final 'submit' page to the customer, a hidden field (which will be posted to the CC processing company's server) should be included. This field should contain all of the order's pertinent data (price, etc), encrypted with the storefront's private key. When the CC processor gets the submit request from the user, they use the storefront's public key to decrypt the contents of this hidden field and compare the values it contains with those on the form submitted by the user to ensure that no monkeying has taken place.
Making copies and ordering parts is not terribly useful practical experience, and isn't likely to lead to Real Work.
My advice to would-be co-ops: Figure out what skills will make them sit up and take notice, and acquire those skills. When I was a senior in HS checking out various colleges, the head of the CS department at one (the one where I ended up) told me that if I knew C or some other common programming language, I'd have no problem finding a co-op job. So I went home, bought a copy of an inexpensive C compiler, and set about teaching myself the language. The department head proved correct: I easily got a job, and was writing real code (in C) just a few weeks after I started working there.
I have to admit, it also helped that I was a programmer surrounded by hardware engineers who didn't have a lot in the way of programming skills. Basically, I was in many ways a "support" person (i.e. the work I was doing wasn't as core to the organization's business), I was trusted with more responsibility than someone who was doing hardware engineering would be.
This only works because you know when the game will end. On a game where you don't know the number of iterations, this strategy is impossible.
If your partner is humming and clipping his nails, he's being a lousy partner. The 'watching' half of the pair is not just sitting there passively; he should be actively participating, keeping track of what has to be done next to keep the rest of the system consistent with the changes you're making now, etc.
You mention trouble with distractions in the office. This is actually one of the values of pair programming that isn't immediately obvious: It's actually a great focuser and shield against distractions. Coworkers who want to pull you into a discussion about last night's must-see-TV are far less likely to try to do so when you're working with a partner. And you're far more likely to be disciplined about ignoring these things, yourself. It's also helped me that I treat pair programming sessions every bit as formally as I do meetings: My partner and I set a time, and come up with an agenda in advance of the actual session.
You guys are all on a hair-trigger with the anti-machoism.
I don't think it qualifies as being in hair-trigger mode to respond strongly to someone who proclaims that "the only programmer I'll allow to watch over my shoulder is a dead programmer". If you want calm, measured responses, you should probably speak in a calm, measured manner yourself.
Let's try this again...
Suffice to say that I'm glad I don't work with you. The sort of egocentric, programming-as-heroism you seem to favor is rarely useful on nontrivial problems that require multiple programmers. Usually it's a cover for massive insecurity. If you're confident in the quality of the code you write, you shouldn't have any problem with a partner reviewing it as you write it.
So far I've had really good experiences with pair programming. No bickering over editors, etc. Just lots of good code produced. I think it's important to choose good partners. IMO, the best pair programming partner is someone who you're well aquainted with and respect (and whose respect you desire), but who isn't a particularly close friend. This makes it far more likely that the 2 of you will remain disciplined and focused on the code. But the key thing to remember is that the goal is to produce working code.
Second of all, the only programmer I'll allow to watch over my shoulder is a dead programmer. And the only way I'll watch some other dimwitted slowpoke feebly hunt-n-peck a single line is if I am allowed to threaten that person with a gun.
To some extent I agree with this. However, what I've seen so far is that the biggest obstacle to software quality is management's unwillingness to allow the engineers to take the time to do things right. Interestingly enough, I hear pretty much exactly the same complaint from friends of mine who are in other engineering discipline.
I should also note that you're making a rather different claim than TechnoWeenie did: He claims that the basic foundations of software engineering (i.e. computer science) are much less stable than those of civil engineering (i.e. physics). You, on the other hand, are claiming that the processes we build on top of those foundations are not yet stable.
I agree that a formal education isn't absolutely necessary to be a good engineer. But it certainly doesn't hurt. It's particularly valuable when you're dealing with other engineers (assuming that they're similarly educated), because you'll find that you simply have a much better developed "common language" for communicating with them.
Nonsense. The legal tradition of our culture tells us that the authors of information have a certain set of rights to specify how and by whom that information may be used. This set of rights has traditionally been far less broad than the set of rights that is implied by the word "property".
I started to respond to this by saying I'd never had any good teachers, but then I started to think a bit harder.
My primary school teachers ranged from forgettable to relentlessly bad.
In secondary school, only one stands out in my memory: Jack Sharpe, my Senior year English Lit teacher. I remember when he told us: "Don't write a thesis paragraph for your essay. If you feel you need to do such a thing to create a good essay, write one and cross it out, and I won't read it." Prior to this, I'd had teachers who taught us to write standardized 5 paragaph (thesis-body-body-body-conclusion) essays, and had a hard time with it. I rarely had well-formed ideas about a work when I sat down to write, so coming up with a specific thesis right from the start was rather difficult for me. So I found his approach quite liberating: It was much easier to get started when I could hold off on specifying a thesis and instead focus on some smaller matter. My essays still had coherent conclusions, but I usually would write the first 2-3 paragraphs before I had a clear idea of what the conclusion would be. I should add that Sharpe also had a lot of enthusiasm for his subject, and showed genuine interest in the interpretations his students would come up with. His class fundamentally changed my attitude towards language/literature classes. I'd previously considered them necessary evils at best. Afterwards, I'd come to feel significant pleasure in the process of analyzing a literary work and writing about my thoughts on it. Despite the fact that I went on to study computer science in college and now work as a programmer, this comfort with writing was by far the most valuable thing I got out of high school.
Good point. Even if these organizations do attempt to close ranks, it only takes one employee with access to the reports and willingness to leak them to ensure that outside parties "discover" the same holes that the club members do.
I'm familiar with this example: I've implemented it myself, although the "shapes" were actually 3D objects being raytraced, not drawn. I was using C++, and that language's features made it possible to very cleanly and elegantly express what I wanted. Since I got comfortable with C++, I won't touch C with a 10 foot pole, unless I absolutely must.
But for the sake of discussion, let's modify your code slightly: Take the case statement and wrap it in a procedure named DrawShape, which will be used consistently throughout the rest of your code. Having done this, it's really a matter of
vs. Now, the second version still has certain disadvantages. Most significantly, you have to manually maintain the DrawShape function yourself, increasing the possibility of bugs (since you might forget to update it, whereas the compiler would never forget to generate vtable entries for a new subclass of some abstract base). This will get even worse when you have multiple programmers creating shape types and needing to maintain a single shared DrawShape function.Still, this scheme means that all changes to how the shape "type hierarchy" works are isolated from the rest of the program. The rest of your code doesn't have to worry about the specific 'subtype' of shape that it's trying to draw at any given time, and if you want to add a Triangle shape type, you merely have to write DrawTriangle (which you have to do, anyways) and add an entry for it to the DrawShape function.
Again: I think that OO is ultimately an approach to constructing programs that is more-or-less independant of the languages we choose for implementation. Some languages may make it more natural, but few make it impossible.
If you just have a data structure and a bunch of procedures that operate on it, then that's just good old-fashioned procedural programming.
What is an object if not a data structure with a bunch of procedures (which are called methods, in this context) that operate on it?
How would you implement polymorphism this way?
I don't see polymorphism as a fundamental property of OOP, but rather a (very useful) tool that is enabled by language-level support for OOP.
I agree that language support for OO is quite helpful, but as I see it, the fundamental characteristic of OOP is that the explicit and formal (though perhaps not language-supported) definition of the data entities in the system and of the legal operations on those entities.
What do you think the "window_init", "window_draw", and "window_destroy" functions were? Just because these functions weren't formally defined as methods of the window_t object doesn't mean that they aren't methods. In the programmer's mind, they're methods, and that's what matters, in the end.
computers still have a long long way to go speed-wise. it's as if you're in 1904 saying "why would a car ever need to go faster than 25 miles per hour?"
besides, people will always be drawn to the faster machine, both by internal competitive drive and by marketing pressure.
Let's try applying the automotive analogy to that last sentence of yours: "People will always be drawn to the faster car". Er, no actually: People base their car buying decisions on many factors, and speed is pretty far down the list for most people, because any car you'll buy will be more than capable of going as fast as you actually want to go in 99% of situations.
Sure, cars had a lot of room for increases in speed in 1904, but eventually those increases leveled off. Who's to say that the same thing can't happen to computers? How can you say with confidence that it isn't happening already?
I know you're joking, but several people have made comments like this, and there seems to be this lurking assumption that the metric system is somehow more "rational" or less arbitrary than other systems.
Why would an alien species use the metric system? A meter is defined as "the distance traveled by light in a vacuum during a period of 1/299,792,458th of a second", and a second, in turn, is defined as "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom".
Now aren't those some weird constants in those definitions? That's because the original definition of the meter and second are actually "one ten-millionth of the distance from the north pole to the equator, along the meridian passing through Paris", and "1/86,400th of a solar day", respectively. The definitions based on physical constants were only made later. To an advanced spacefaring civilization, basing a unit of length some physical attribute of a particular planet is just as silly and provincial as basing it on the physical attribute of a particular person (i.e. the king).
The only non-arbitrary part of the metric system is the factor-of-10 relationship between different units of the same type. And that's still a little arbitrary: A factor of 10 makes sense to us because we use the decimal system, which is something that, in turn, we do because we have 10 fingers. To an alien race that has 16 tentacles, it's a bit inconvenient.
In measurement, what's important is that everyone use the same standard. That is the primary reason to go with metric: most other people already do. The intrinsic qualities of the system are far less important.
Where does he actually say this?
Answer: Nowhere.
The goal stated on the philosophy page is to provide a smoother path into programming so that anyone can become a programmer. Not to require everyone to become a programmer.
The fact is, despite enormous amounts of effort that have been put into building user interfaces that will put power and flexibility into the hands of nonprogrammers, these interfaces still provide only a fraction of the power that programmers enjoy. An approach that lowers the barriers to "programmer-hood" may prove to be a more fruitful path to putting real utility into the hands of the common person.
The goal isn't to have the average person writing applications from scratch. The goal is to make it possible for the average person to adjust the functioning of existing applications to better suit their needs, to write small scripts that automate common tasks, etc.
Whether or not this is an attainable goal is another question entirely, but I certainly can't fault the guy for trying.
You miss his point. The measure of the RBL's usefulness isn't merely how good it is at punishing spammers, but rather, how good it is at doing so, while avoiding punishing non-spammers. If the RBL frequently lists addresses unjustly, eventually people will lose respect for it and stop using it.
I mean, I could stop all spam by unplugging my machine from the network. Somehow this strikes me as a less-than-ideal solution, though.
I've visited a couple of times (Paris only), and had similar experiences. However, I didn't find that speaking French well was a necessity - mine is limited to "oui", "non", "merci", and "parle vous anglais?", and never encountered anything I would call rudeness. I think the key was that I didn't assume anybody spoke American - I prefaced pretty much every conversation with that last phrase. For that matter, don't assume that too much of anything will be like it is in the US, and you'll probably get along okay.
And Paris is indeed beautiful. I'm toying with the idea of taking a few classes in french so that I could maybe live and work there for a few years.