Now, before the internet, you would have to be familiar with librarys and card catalogs -- learning how to use those efficiently would have been of much greater value than memorizing a bunch of discrete facts. Today, the internet can provide a great deal of information in the same way, and learning how to navigate it through search tools is far more valuable than the individual bits of information a search turns up.
No, the only major difference today is that card catalogs are becoming obsolete, because library catalogs are now online. Despite what the techie fanboys would have you believe, the best source of information is still in paper form, not on the internet, and despite what Google would like you to believe, the vast majority of that information is not going to be freely available online any time soon; the commercial interest just isn't there.
There is really no substitute for going to the stacks in a good library, going to a shelf where books and journals for the topic of interest are, and just skimming over them one by one, taking notes about what they say, and most importantly, about which other works they cite. People who acquire the habit of doing this are the true scholars.
Or, in other words, there's this whole dimension to your "learning to learn" things that you've seemingly not learned.
I think the whole "information overload" thing boils down to a lot of people who didn't learn "how to learn". If you learned how to discover new information in the most general sense, and on your own, the internet is not a source of frustration or overload -- it's a repository of all those things it doesn't make sense to store in your head.
No, the internet is a computer network. It delivers bytes from one host to another, and it doesn't care whether those bytes are valuable information, misinformation, or whether there is any host on the network that has the information you need. There are plenty of topics for which it doesn't.
No amount of Googling will be of any help if the information you're want is only available in paper form in Portugal, in archives of documents about the administration of its former African colonies, with no plans to put any of it online, and worse, if you don't know Portuguese. You just have to learn Portuguese, travel to Lisbon, and spend a couple of weeks working through a lot of paper.
It can't, but that is not the point. The trival comments indicate that the method is doing something trivial, as against something non-trivial (see below).
I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
If on the other hand I'm reading the source code, then lahi's point applies--I can just see that the method is a trivial instance field access.
This is potentially limiting, as it tries to make accessor functions limited and special in what they do.
No, you've failed to understand the feature here. There's no limitation at all. In the case of Ruby, for example, there are no publicly accessible instance fields at all. All interaction with an object must be through method invocations. If you need trivial getters and setters, there's a class method that uses the language's dynamic features to define them for you on the fly--you just say attr_accessor:foo,:bar, and voilà, you've got yourself getters and setters for foo and bar. If you need non-trivial getters or setters, you just write them by hand.
And what's even neater is that this is not a hardcoded feature of the language--attr_accessor is just a method that exploits Ruby's dynamicity; namely, the ability to generate code and extend a class at runtime. You can write attr_accessor in Ruby itself. Which means that (a) you can write your own custom boilerplate runtime method generation code just as easily, (b) you don't need a separate tool (i.e., an IDE) that knows how to parse your code and potentially decipher intent ("hmm, these two methods must be a getter/setter pair"), and most importantly, (c) the logic that decides what it means for something to be an accessor pair, and the implementation thereof, reside in just one place, instead of all over the damn code.
It also follows that you hardly ever need to write proxy classes. You can trivially write a function that takes a class, and spits out a delegate class; and the standard library already provides such code. You subclass this latter one with a constructor that sets the object that you're delegating to, and override whichever methods are different, and you're done.
[...] it is perfectly acceptable for a Java class 'bean property' (indicated by the presence of setXXX or getXXX methods) to not actually exist as an instance variable in the class. What may look like a simple accessor is actually getting a value by some other mechanism. However, to the code that uses this class (or looks at its properties by introspection) this is nicely hidden. This allows things like proxy instances to work neatly - the apparent accessor functions actually divert to another instance to retrieve or store values.
You can't really reconcile encapsulation and documenting trivial implementations. If the point of getters and setters is to encapsulate access to conceptual "properties" of objects, then whether a particular getter/setter pair is trivial is exactly the sort of thing we're trying to hide from the clients, and thus, it's not relevant information for the comment.
As to proxies: I've had to write proxy implementations of the JDBC interfaces. Ugh, that is hell.
IIRC, he and his wife were preparing to go out as missionaries back in the late 1970s, and to that effect, he studied linguistics, and was involved with the Summer Institute of Linguistics. He got sick, had to go into computer work instead. I don't think he's ever published any work in linguistics, or even presented at a linguistics conference--at least I never found any record of such when I searched the field's databases. And frankly, whenever he does invoke his knowledge of linguistics, it strikes me that he knows no more than a lot of amateur linguistics enthusiasts out there--which is more than the average person, but not a lot.
My take on it is that it's a pretty transparent situation--what he really wanted to be was a missionary linguist, and he never got to be that, but it's still important enough to his self-identity that he mentions it left and right. I find the whole thing a little bit dodgy, but way less so than ESR's practice of calling himself an "anthropologist" (or more precisely, "an observer-participant anthropologist in the Internet hacker culture"), which in his case I think most accurately translates as "a fraud."
Anyway, here's the lesson, kids: calling yourself fancy titles that other people haven't given you tends to mess up your reputation among those in the know.
Many people have written such apps, they are called servers. Anything that binds on a privileged port requires root access.
And that latter sentence is not something to be bragging about when the topic is security, because it means that in order for an app to have access to one small, well-defined resource (a particular port), it needs to be given uncontrolled access to all of the computer. That is, the granularity of permissions is not fine enough.
Whenever the 100$ laptop is mentioned, the hordes scream: "Africa needs food! Africa needs schools!". Well, they've been receiving food and aid for decades, and they're still poor. Maybe it's time to try something different.
Yeah, like autochtonous economic development, something that first world nations have been fighting extremely hard for the past few decades. And guess what, food "aid" is in fact aid for the givers.
It ends with "Ultimately the TPM itself isn't inherently evil or good. It will depend entirely on how it's used, and in that sphere, market and political forces will be more important than technology."... ugh. Well we all know what that means."
Of course, as faithful slashbots, we sure do. It means exactly the opposite as it does when the same is said in the context for file "sharing."
Personally, I suspect that Wikipedia's method is a somewhat viable way to shuffle out the stupids, as true statements will be less likely to be edited than untrue statements, so gradually over time Wikipedia will tend to be more and more likely to contain true statements.
You're making a very basic mistake that most Wikipedia zealots make over and over--equating the quality of an article with the likelihood of containing true statements.
This is fundamentally misguided, because it leaves out a whole set of issues about identifying the target audience of an article, the purposes they have when they consult the article, and how well the article serves those purposes. No matter what proportion of statements within an article are true, that is of very little use if the article is not actually helpful, which it may not be for many reasons: it may fail to be well organized, it may fail to convey the basic ideas of a topic, etc.
To put it more crudely: a lot of Wikipedia "articles" read like a disorganized shopping list of random facts about their topic put together by a bunch of people who never seriously tried to coordinate, and just idly added individual "true statements" to an article, without any concern for its organization or actual usefulness. They read like that because, well, that's exactly what they are. (And the worst part is that Wikipedia makes the people who do this feel good about what great guys they are to "contribute" their "knowledge" for the greater good...)
But I digress. Bringing in the idea that the quality of an article has to do with how well it serves its target audience, I believe, leads to an uncommon conclusion: since there is no effectively enforced standard about what's the target audience and use for any given Wikipedia article, it follows that there is no way to judge the quality of Wikipedia articles. A Wikipedia article is of high quality to the extent that it meets its intended use. But what is that intended use? God knows.
PS another interesting observation about equating quality with proportion of truths: it is in fact very often the case that to explain a topic to a beginner, the most effective way to do it is by telling them things that you actually don't believe are true, and are ready to admit as such. Why? Because regardless of their truth, they are an exemplar application of the fundamental ideas of the topic. The really important thing that distinguishes an expert in a topic is not the set of facts they believe to be true about it (which in fact might change very often), but the way they think about the topic. Correspondingly, an expert's errors can actually be extremely instructive material, even uncorrected. The "fact accumulation" idea just fails to distinguish what's important in a topic from what's not, and as such, reflects a lack of understanding.
Gödel, Escher, Bach is single-handedly responsible for making too many damn kids who think they're smart feel like they understand mathematical logic and Gödel's incompleteness theorems. Sure, it's an amusing read, but a large part of it is because it's really a stroke-your-own-ego kind of book ("I'm so teh smart, I can understand 1337 intellectual stufferz!").
Not to mention the risible "arguments" for strong AI that the book makes. Like the part where Hoftstatdter states Lucas' argument against strong AI, and then proceeds to just say that he doesn't think it's right, without even bothering to address it...
The point of the SLR was to be able to look through the lens and see exactly what the lens was seeing. With a digital viewfinder, who needs all that extra mechanical crap?
Somebody who actually wants to see exactly what the lens is seeing, of course, as opposed to a low-resolution digital rendering thereof. You know, so as to see the subject of the picture in detail before you shoot it.
The only conclusion I can come to is that the camera makers are adding the SLR to appeal to "traditional" photographers.
Indeed. Your problem is that you've failed to conclude that those "traditional" photographers might be on to something.
C/C++ doesn't prevent you from coding secure, leak-free programs. All it does is shift the responsibility for security and memory management from the language to the programmer. If you're a sloppy programmer then, yes, you need a better language than C/C++.
Experience demonstrates that, by and large, even very good programmers commit a sizeable number of these errors. Not to mention that ensuring proper security and memory management takes time; and time is money.
I think it's perfectly fine to subscribe to the OP's take on this: a language is purely object oriented if all instances of all types are objects, except for the ones that aren't.
#1. Show how ID is not scientific because it cannot be falsified.
Ah, the good old Popperian argument, as transmitted to common scientific wisdom. There's a simple problem with it: it doesn't work. In more than one way.
First, Quine showed that you can't falsify any one individual hypothesis, nor distinguish in general between "empirical" and "non-empirical" statements (or "observational" from "theoretical," or whatever). Why? Well, the falsification procedure requires you to state a hypothesis H, and then infer that if H is true, then you must observe P. If in actual fact you observe not P, then h must be false.
The problem here, however, is that to get from the hypothesis H to the expected observation P, you're going to need extra assumptions. The fact that you observe not P doesn't logically require that H be false; it requires that at least one thing in the union of H and the extra hypotheses be false. In other words, no amount of evidence can make you abandon H, as long as you're willing to sacrifice some other assumption.
Second problem: scientists make extensive use of statistics to analyze experimental data. Strictly speaking, experimental data pretty much always falsifies the hypothesis; when you plot the data points and the curve predicted by the hypothesis, they never match. We use statistical techniques to measure how close of a match there is, and thus say that the data support or fail to support the hypothesis, depending on whether the statistical degree of confidence is higher than a conventional threshold. The experiment never falsifies or confirms the data, it just changes the confidence we assign to the hypothesis (and, again, as per the first point, given other assumptions that we just happen to be less willing to abandon).
Third, more general, and more important (and controversial): traditional writings on the philosophy of science just have very little to do with the actual practice of science. They're philosophical fantasies aimed at giving scientifically-oriented people a warm and fuzzy feeling about how their work allows them to uncover pure, objective, empirical truth, untarnished by human interests and frailities. This picture has very little to do with the real world, where scientists participate as members of our society, competing in a market for research funding and publication, facing pressures to deliver results by timelines, and so on.
A basic rule to interpreting the frequency response figures that manufacturers cite for headphones is that they're all lies of omission. More precisely, they involve setting a really low threshold for what counts as "response" at any given frequency.
So sure, your headphone's manufacturer put your headphones in a testing setup, and demonstrated that the headphones produced some output at, say, 15 Hz. But, what's the level of that output compared to the level of the output for an equally strong electric signal at, say, 1 KHz? Is it 3dB lower? (That'd be really good, but I seriously doubt that one.) 6dB? (That wouldn't be bad at all.) 9dB? (That's not good, really.) 12dB? (Ridiculous.) The bigger that number, the less the cited figures mean; and you see that many manufacturers don't bother to mention the tolerance for their cited figures.
For example, Sennheiser's HD650, their top of the line dynamic headphone, is listed as "10 - 39,500 Hz (-10dB)." These guys, in practice, can definitely put out a reasonable 30 Hz, and start to roll off down from there; you get some meaningful output in the 20Hz region, but it's definitely lower than in the midrange.
And this is from a set of headphones that retails for over $300. Did you spend that much on your headphones?
The Africans were simply uninterested in doing for themselves what external nations were willing to do for them. As long as the Red Cross kept the bags of oats coming, it wasn't worth it to the "farmers" to go out of their way to produce the food locally.
That's quite a biased way to put the very real problem that flooding a country with extremely low-cost foreign products means that local producers can't even hope to compete. You know, investing resources to produce something you can't sell is not exactly financially smart. You're better off doing nothing.
And this sort of stuff has happened in the USA, too, and in an even more absurd manner--the stereotypical economic depression scenario where there's a food shortage in the cities when agriculture overproduces, because the price that could be obtained for food is just too low to justify spending more on production and distribution. Which led to those New Deal government incentives for farmers to actually reduce yields...
I think you're still missing the two fundamental problems (or rather, two sides of the same coin):
The distinction between "the application" and "the database" is a bit arbitrary.
Our databases suck.
On the first point: note that I said "a bit" arbitrary, and not completely so. There are excellent reasons why we separate the application and the database. Or rather, the applications (a plural that says a lot) and the database. Still, the difference between the database and the application should be considerably more seamless.
On the second point: if you want me to program in PL/SQL, you might as well murder me.
As to where business logic belongs, I think the best answer is that you should only have to write and maintain the business logic in one place and form. If that didn't sound like an answer to the question, well, that's because the question poses a false dichotomy. Whether the business logic resided on the application or in the database server is an implementation detail that the language used for implementing said logic should abstract away. You should just be able to write down the logic once, and the same set of rules should be able to run on either side. Or even better: on both at once. (Why? Because they serve different functions: the database might the rules to protect data integrity, while the application is in a better position to interpret violations and deal with them smartly.)
A real-life system I've seen implemented that's kind of similar to the idea: a little domain-specific language for web form validation, that does double duty: it's used on the web server to validate form submissions, but at the same time, it gets compiled to Javascript that gets embedded on the web page and detects invalid submissions at the client side. Again, the same business rules, but they transparently work in more than one implementation. (And there's no reason why in principle the same rules couldn't be translated into database constraints; but doing it in practice might be hell. As I too often say: it's a sad world where the best database is Oracle...)
I think a better analogy is with MySQL as a bus, and Oracle as the 747. The biggest problem with MySQL, historically, has not been that it does the same things as Oracle does but at a smaller scale (Cessna vs. 747), but rather, that it just hasn't had a lot of crucial database management features (like constraints; or more generally, the fact that MySQL just wasn't designed with data integrity in mind at all, and it's been tacked on later).
So yeah, of course, Cessnas should definitely be more common than Boeings, but buses don't fly at all.
A lot of audiophile CD players and DACs do this; they upsample CD audio to 24 bit and 96 or 192 kHz before converting to analog. It's claimed that this improves the quality of the analog playback signal. I've never really bothered to try and understand it, so don't ask me. A Google search for upsampling audio turns up a few relevant articles in the first page.
This is not so with Python, whose design is in fact evolving to discourage a functional programming style (Guido has repeatedly rejected adding anonymous closures to the language, and is planning to get rid of built-in functional combinators like map and reduce).
That's because list comprehensions, generators, and inner functions do the same thing in a more Pythonic way.
Or, in other words, list comprehensions, generators and inner functions are designed to discourage a functional programming style.
Fortunately, Python 2.5 is going to have context managers with a much nicer syntax than the Ruby syntax [...]
First, by "much nicer syntax" you must mean "with a syntax that I'm already used to." (OTOH, I spend all day programming Scheme, so you probably think I'm a loony anyway when it comes to syntax.)
Anyway, yeah. The Python language is going to be revised to add yet another special-purpose feature and syntax to do yet another specific thing that any language with closures can do trivially with a higher-order function, without any revisions to the language.
And then it's going to take a while for the revisions to be available in all of the implementations of Python, and for third-party libraries to catch up with the language and implement APIs that use this feature. Sure. Sounds great.
Same story with list comprehensions, generators and generator expressions. Ruby, Scheme, and other such languages don't have any of those. Instead, they've had anonymous lexical closures since the start. For example, Python required a new language version to implement generators; in Ruby, the same functionality was implemented as a standard library, and to boot, it was implemented in Ruby itself.
You're saying that a statement that does *less* than the other one is easier to understand. Way to go, Sherlock.
Now let's try a comparison between statements that do the *same* thing. First, the one using the block to manage resource allocation and deallocation:
Net::HTTP.start( 'www.ruby-lang.org', 80 ) do |http| print( http.get( '/en/LICENSE.txt' ).body ) end
...and second, the *real* equivalent without blocks:
begin http = Net::HTTP.start( 'www.ruby-lang.org', 80 ) print( http.get( '/en/LICENSE.txt' ).body ) ensure http.close end
Needless to say, the block version is shorter.
Anyway, this pattern you see here is one of the most common Ruby idioms, which you should get the hang of if you're learning the language: using blocks to decouple code that manages a resource *through its whole lifecycle* from code that use the resource. It's always like this:
Resource.acquire {|resource| # do stuff that requires resource } # resource has been released, without you having to say so, # even if the there was an exception
The same pattern applies to files, network connections, database result sets, thread locks, anything. Sure, it's unfamiliar to *you*, but you only need to learn the pattern *once*, and you reuse it all the time for different kinds of resources.
And to top it off, you can write your own methods like acquire() above in Ruby itself, just by using yield. This is not some special syntax sugar for resource management--this is just blocks. Here's the pattern for writing a method like acquire():
def acquire begin resource = low_level_acquire() yield resource ensure resource.low_level_release() end end
For a language to be functional it is essential to restrict side effects (haskell with monads, ocaml with 'mutable'), or at least have some good support for no-side-effects programming: currying, higher-order functions, the "let x = expr1 in expr2" (aka non-destructive assignment) construct and so on.
I don't think any of these features, other than higher-order functions, is really essential. Though if you rework the "let x = expr1 in expr2" as "lexical scoping," I might accept that (though I'd still point out that let is "really" just lambda: "((lambda (x) expr2) expr1)"). Scheme is routinely labeled as a functional language, and it has side effects. Cons pairs in Lisp in general are mutable.
Anyway, I think asking whether a language is "functional" is not as good of an exercise as seeing functional programming as a programming style or set of techniques, and then asking how much support a language provides for using that style, and how natural it is to use it in that language.
Ruby is no more functional than Python, even by the most twisted definition of 'functional'. Yup, it uses closures (aka blocks) and that is how far it goes towards functional. [...] Both Python and Ruby make routine use of destructive assignment, which is the epithome of side effects.
Here I'd respond that Ruby provides much more natural support for higher-order functions (because of blocks), its libraries are designed around them. It's actualy hard to avoid using them any time you program in Ruby.
This is not so with Python, whose design is in fact evolving to discourage a functional programming style (Guido has repeatedly rejected adding anonymous closures to the language, and is planning to get rid of built-in functional combinators like map and reduce).
What's non-functional about Ruby? I'd say the biggest thing is the fact that its default sequence datatype is a flexible array type, and not a singly-linked list type.
Yeah, I was reading that a couple weeks ago. Lesson I got out of it (might be wrong, but if it is, it's wrong in a good way): all linear recursion, deep down, boils down to "copying" some recursive "data structure"; scare quotes because you get to pick your own "fake" constructors, destructors and type predicates. Thus, linear recursion boils down to "copying" a "list," and iteration (i.e. tail recusion) boils down to "reversing" a "list."
Some Scheme-ish code might make this clearer. Here's the list copy function in Scheme:
Pretty straightforward. The null? predicate tests whether its argument is an empty list; car and cdr return the first element of the list and the rest of the list, respectively; cons takes an element and a list, and gives you a new list with that element in front of the old list.
Now take that function, and change it so that instead of using the "real" null?, cons, empty list, car and cdr, we use "fake" ones, that we just pass in as arguments:
Now you can write *any* linear recursive function as an application of fake-list-copy. For example, computing the factorial of n. Suppose you had a singly linked list that started with n, and had each subsequent element one less than the previous one, down to 1; for example, for the factorial of 5, that you had the list (5 4 3 2 1). Now, if you use the real null?, car and cdr, but use multiplication and 1 as your fake-cons and fake-empty-list, then (fake-list-copy * 1 null? car cdr '(5 4 3 2 1)) gets you the factorial of 5.
Of course, building those lists is inefficient. But we don't have to build them. We can represent each list as a number:
With that representation, we can choose appropriate functions to use as fake-null?, fake-car and fake-cdr. We use zero? as fake-null?, identity as fake-car (identity just returns its argument without altering it), and decrement as fake-cdr. Thus, the following will compute factorial recursively:
Of course, doing this recursively takes up stack space. But you can do it without stack space by basing the whole thing on abstracting the definition of a function to reverse lists, instead of one for copying them. That's left as an exercise for the reader...
And of course, after we master all that, just to sound smart, we will thereafter call the fake-list-copy function a "list hylomorphism"...
That shouldn't be called "Avoid Recusion," because you're not really avoiding recursion. What you're doing (as the wiki itself explains) is abstracting it into a higher-order function.
Still a pretty damn important technique that one should master in functional languages--recognizing the "shape" of a loop (is it a map? a left or right fold? an unfold?), and implementing the looping logic as a higher-order function separately from its specific uses.
Slashdot Mirror
That's all there is to it.
Um, so, you cite Wikipedia to support your claim. How do we know that it wasn't you who wrote the Wikipedia text you cite, anyway?
No, the only major difference today is that card catalogs are becoming obsolete, because library catalogs are now online. Despite what the techie fanboys would have you believe, the best source of information is still in paper form, not on the internet, and despite what Google would like you to believe, the vast majority of that information is not going to be freely available online any time soon; the commercial interest just isn't there.
There is really no substitute for going to the stacks in a good library, going to a shelf where books and journals for the topic of interest are, and just skimming over them one by one, taking notes about what they say, and most importantly, about which other works they cite. People who acquire the habit of doing this are the true scholars.
Or, in other words, there's this whole dimension to your "learning to learn" things that you've seemingly not learned.
I think the whole "information overload" thing boils down to a lot of people who didn't learn "how to learn". If you learned how to discover new information in the most general sense, and on your own, the internet is not a source of frustration or overload -- it's a repository of all those things it doesn't make sense to store in your head.
No, the internet is a computer network. It delivers bytes from one host to another, and it doesn't care whether those bytes are valuable information, misinformation, or whether there is any host on the network that has the information you need. There are plenty of topics for which it doesn't.
No amount of Googling will be of any help if the information you're want is only available in paper form in Portugal, in archives of documents about the administration of its former African colonies, with no plans to put any of it online, and worse, if you don't know Portuguese. You just have to learn Portuguese, travel to Lisbon, and spend a couple of weeks working through a lot of paper.
I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
If on the other hand I'm reading the source code, then lahi's point applies--I can just see that the method is a trivial instance field access.
This is potentially limiting, as it tries to make accessor functions limited and special in what they do.
No, you've failed to understand the feature here. There's no limitation at all. In the case of Ruby, for example, there are no publicly accessible instance fields at all. All interaction with an object must be through method invocations. If you need trivial getters and setters, there's a class method that uses the language's dynamic features to define them for you on the fly--you just say attr_accessor :foo, :bar, and voilà, you've got yourself getters and setters for foo and bar. If you need non-trivial getters or setters, you just write them by hand.
And what's even neater is that this is not a hardcoded feature of the language--attr_accessor is just a method that exploits Ruby's dynamicity; namely, the ability to generate code and extend a class at runtime. You can write attr_accessor in Ruby itself. Which means that (a) you can write your own custom boilerplate runtime method generation code just as easily, (b) you don't need a separate tool (i.e., an IDE) that knows how to parse your code and potentially decipher intent ("hmm, these two methods must be a getter/setter pair"), and most importantly, (c) the logic that decides what it means for something to be an accessor pair, and the implementation thereof, reside in just one place, instead of all over the damn code.
It also follows that you hardly ever need to write proxy classes. You can trivially write a function that takes a class, and spits out a delegate class; and the standard library already provides such code. You subclass this latter one with a constructor that sets the object that you're delegating to, and override whichever methods are different, and you're done.
[...] it is perfectly acceptable for a Java class 'bean property' (indicated by the presence of setXXX or getXXX methods) to not actually exist as an instance variable in the class. What may look like a simple accessor is actually getting a value by some other mechanism. However, to the code that uses this class (or looks at its properties by introspection) this is nicely hidden. This allows things like proxy instances to work neatly - the apparent accessor functions actually divert to another instance to retrieve or store values.
You can't really reconcile encapsulation and documenting trivial implementations. If the point of getters and setters is to encapsulate access to conceptual "properties" of objects, then whether a particular getter/setter pair is trivial is exactly the sort of thing we're trying to hide from the clients, and thus, it's not relevant information for the comment.
As to proxies: I've had to write proxy implementations of the JDBC interfaces. Ugh, that is hell.
My take on it is that it's a pretty transparent situation--what he really wanted to be was a missionary linguist, and he never got to be that, but it's still important enough to his self-identity that he mentions it left and right. I find the whole thing a little bit dodgy, but way less so than ESR's practice of calling himself an "anthropologist" (or more precisely, "an observer-participant anthropologist in the Internet hacker culture"), which in his case I think most accurately translates as "a fraud."
Anyway, here's the lesson, kids: calling yourself fancy titles that other people haven't given you tends to mess up your reputation among those in the know.
And that latter sentence is not something to be bragging about when the topic is security, because it means that in order for an app to have access to one small, well-defined resource (a particular port), it needs to be given uncontrolled access to all of the computer. That is, the granularity of permissions is not fine enough.
Yeah, like autochtonous economic development, something that first world nations have been fighting extremely hard for the past few decades. And guess what, food "aid" is in fact aid for the givers.
Of course, as faithful slashbots, we sure do. It means exactly the opposite as it does when the same is said in the context for file "sharing."
You're making a very basic mistake that most Wikipedia zealots make over and over--equating the quality of an article with the likelihood of containing true statements.
This is fundamentally misguided, because it leaves out a whole set of issues about identifying the target audience of an article, the purposes they have when they consult the article, and how well the article serves those purposes. No matter what proportion of statements within an article are true, that is of very little use if the article is not actually helpful, which it may not be for many reasons: it may fail to be well organized, it may fail to convey the basic ideas of a topic, etc.
To put it more crudely: a lot of Wikipedia "articles" read like a disorganized shopping list of random facts about their topic put together by a bunch of people who never seriously tried to coordinate, and just idly added individual "true statements" to an article, without any concern for its organization or actual usefulness. They read like that because, well, that's exactly what they are. (And the worst part is that Wikipedia makes the people who do this feel good about what great guys they are to "contribute" their "knowledge" for the greater good...)
But I digress. Bringing in the idea that the quality of an article has to do with how well it serves its target audience, I believe, leads to an uncommon conclusion: since there is no effectively enforced standard about what's the target audience and use for any given Wikipedia article, it follows that there is no way to judge the quality of Wikipedia articles. A Wikipedia article is of high quality to the extent that it meets its intended use. But what is that intended use? God knows.
PS another interesting observation about equating quality with proportion of truths: it is in fact very often the case that to explain a topic to a beginner, the most effective way to do it is by telling them things that you actually don't believe are true, and are ready to admit as such. Why? Because regardless of their truth, they are an exemplar application of the fundamental ideas of the topic. The really important thing that distinguishes an expert in a topic is not the set of facts they believe to be true about it (which in fact might change very often), but the way they think about the topic. Correspondingly, an expert's errors can actually be extremely instructive material, even uncorrected. The "fact accumulation" idea just fails to distinguish what's important in a topic from what's not, and as such, reflects a lack of understanding.
Not to mention the risible "arguments" for strong AI that the book makes. Like the part where Hoftstatdter states Lucas' argument against strong AI, and then proceeds to just say that he doesn't think it's right, without even bothering to address it...
Somebody who actually wants to see exactly what the lens is seeing, of course, as opposed to a low-resolution digital rendering thereof. You know, so as to see the subject of the picture in detail before you shoot it.
The only conclusion I can come to is that the camera makers are adding the SLR to appeal to "traditional" photographers.
Indeed. Your problem is that you've failed to conclude that those "traditional" photographers might be on to something.
Experience demonstrates that, by and large, even very good programmers commit a sizeable number of these errors. Not to mention that ensuring proper security and memory management takes time; and time is money.
I think it's perfectly fine to subscribe to the OP's take on this: a language is purely object oriented if all instances of all types are objects, except for the ones that aren't.
Ah, the good old Popperian argument, as transmitted to common scientific wisdom. There's a simple problem with it: it doesn't work. In more than one way.
First, Quine showed that you can't falsify any one individual hypothesis, nor distinguish in general between "empirical" and "non-empirical" statements (or "observational" from "theoretical," or whatever). Why? Well, the falsification procedure requires you to state a hypothesis H, and then infer that if H is true, then you must observe P. If in actual fact you observe not P, then h must be false.
The problem here, however, is that to get from the hypothesis H to the expected observation P, you're going to need extra assumptions. The fact that you observe not P doesn't logically require that H be false; it requires that at least one thing in the union of H and the extra hypotheses be false. In other words, no amount of evidence can make you abandon H, as long as you're willing to sacrifice some other assumption.
Second problem: scientists make extensive use of statistics to analyze experimental data. Strictly speaking, experimental data pretty much always falsifies the hypothesis; when you plot the data points and the curve predicted by the hypothesis, they never match. We use statistical techniques to measure how close of a match there is, and thus say that the data support or fail to support the hypothesis, depending on whether the statistical degree of confidence is higher than a conventional threshold. The experiment never falsifies or confirms the data, it just changes the confidence we assign to the hypothesis (and, again, as per the first point, given other assumptions that we just happen to be less willing to abandon).
Third, more general, and more important (and controversial): traditional writings on the philosophy of science just have very little to do with the actual practice of science. They're philosophical fantasies aimed at giving scientifically-oriented people a warm and fuzzy feeling about how their work allows them to uncover pure, objective, empirical truth, untarnished by human interests and frailities. This picture has very little to do with the real world, where scientists participate as members of our society, competing in a market for research funding and publication, facing pressures to deliver results by timelines, and so on.
A basic rule to interpreting the frequency response figures that manufacturers cite for headphones is that they're all lies of omission. More precisely, they involve setting a really low threshold for what counts as "response" at any given frequency.
So sure, your headphone's manufacturer put your headphones in a testing setup, and demonstrated that the headphones produced some output at, say, 15 Hz. But, what's the level of that output compared to the level of the output for an equally strong electric signal at, say, 1 KHz? Is it 3dB lower? (That'd be really good, but I seriously doubt that one.) 6dB? (That wouldn't be bad at all.) 9dB? (That's not good, really.) 12dB? (Ridiculous.) The bigger that number, the less the cited figures mean; and you see that many manufacturers don't bother to mention the tolerance for their cited figures.
For example, Sennheiser's HD650, their top of the line dynamic headphone, is listed as "10 - 39,500 Hz (-10dB)." These guys, in practice, can definitely put out a reasonable 30 Hz, and start to roll off down from there; you get some meaningful output in the 20Hz region, but it's definitely lower than in the midrange.
And this is from a set of headphones that retails for over $300. Did you spend that much on your headphones?
That's quite a biased way to put the very real problem that flooding a country with extremely low-cost foreign products means that local producers can't even hope to compete. You know, investing resources to produce something you can't sell is not exactly financially smart. You're better off doing nothing.
And this sort of stuff has happened in the USA, too, and in an even more absurd manner--the stereotypical economic depression scenario where there's a food shortage in the cities when agriculture overproduces, because the price that could be obtained for food is just too low to justify spending more on production and distribution. Which led to those New Deal government incentives for farmers to actually reduce yields...
On the first point: note that I said "a bit" arbitrary, and not completely so. There are excellent reasons why we separate the application and the database. Or rather, the applications (a plural that says a lot) and the database. Still, the difference between the database and the application should be considerably more seamless.
On the second point: if you want me to program in PL/SQL, you might as well murder me.
As to where business logic belongs, I think the best answer is that you should only have to write and maintain the business logic in one place and form. If that didn't sound like an answer to the question, well, that's because the question poses a false dichotomy. Whether the business logic resided on the application or in the database server is an implementation detail that the language used for implementing said logic should abstract away. You should just be able to write down the logic once, and the same set of rules should be able to run on either side. Or even better: on both at once. (Why? Because they serve different functions: the database might the rules to protect data integrity, while the application is in a better position to interpret violations and deal with them smartly.)
A real-life system I've seen implemented that's kind of similar to the idea: a little domain-specific language for web form validation, that does double duty: it's used on the web server to validate form submissions, but at the same time, it gets compiled to Javascript that gets embedded on the web page and detects invalid submissions at the client side. Again, the same business rules, but they transparently work in more than one implementation. (And there's no reason why in principle the same rules couldn't be translated into database constraints; but doing it in practice might be hell. As I too often say: it's a sad world where the best database is Oracle...)
So yeah, of course, Cessnas should definitely be more common than Boeings, but buses don't fly at all.
A lot of audiophile CD players and DACs do this; they upsample CD audio to 24 bit and 96 or 192 kHz before converting to analog. It's claimed that this improves the quality of the analog playback signal. I've never really bothered to try and understand it, so don't ask me. A Google search for upsampling audio turns up a few relevant articles in the first page.
Or, in other words, list comprehensions, generators and inner functions are designed to discourage a functional programming style.
First, by "much nicer syntax" you must mean "with a syntax that I'm already used to." (OTOH, I spend all day programming Scheme, so you probably think I'm a loony anyway when it comes to syntax.)
Anyway, yeah. The Python language is going to be revised to add yet another special-purpose feature and syntax to do yet another specific thing that any language with closures can do trivially with a higher-order function, without any revisions to the language.
And then it's going to take a while for the revisions to be available in all of the implementations of Python, and for third-party libraries to catch up with the language and implement APIs that use this feature. Sure. Sounds great.
Same story with list comprehensions, generators and generator expressions. Ruby, Scheme, and other such languages don't have any of those. Instead, they've had anonymous lexical closures since the start. For example, Python required a new language version to implement generators; in Ruby, the same functionality was implemented as a standard library, and to boot, it was implemented in Ruby itself.
You're saying that a statement that does *less* than the other one is easier to understand. Way to go, Sherlock.
Now let's try a comparison between statements that do the *same* thing. First, the one using the block to manage resource allocation and deallocation:
Net::HTTP.start( 'www.ruby-lang.org', 80 ) do |http|
print( http.get( '/en/LICENSE.txt' ).body )
end
...and second, the *real* equivalent without blocks:
begin
http = Net::HTTP.start( 'www.ruby-lang.org', 80 )
print( http.get( '/en/LICENSE.txt' ).body )
ensure
http.close
end
Needless to say, the block version is shorter.
Anyway, this pattern you see here is one of the most common Ruby idioms, which you should get the hang of if you're learning the language: using blocks to decouple code that manages a resource *through its whole lifecycle* from code that use the resource. It's always like this:
Resource.acquire {|resource|
# do stuff that requires resource
}
# resource has been released, without you having to say so,
# even if the there was an exception
The same pattern applies to files, network connections, database result sets, thread locks, anything. Sure, it's unfamiliar to *you*, but you only need to learn the pattern *once*, and you reuse it all the time for different kinds of resources.
And to top it off, you can write your own methods like acquire() above in Ruby itself, just by using yield. This is not some special syntax sugar for resource management--this is just blocks. Here's the pattern for writing a method like acquire():
def acquire
begin
resource = low_level_acquire()
yield resource
ensure
resource.low_level_release()
end
end
I don't think any of these features, other than higher-order functions, is really essential. Though if you rework the "let x = expr1 in expr2" as "lexical scoping," I might accept that (though I'd still point out that let is "really" just lambda: "((lambda (x) expr2) expr1)"). Scheme is routinely labeled as a functional language, and it has side effects. Cons pairs in Lisp in general are mutable.
Anyway, I think asking whether a language is "functional" is not as good of an exercise as seeing functional programming as a programming style or set of techniques, and then asking how much support a language provides for using that style, and how natural it is to use it in that language.
Ruby is no more functional than Python, even by the most twisted definition of 'functional'. Yup, it uses closures (aka blocks) and that is how far it goes towards functional. [...] Both Python and Ruby make routine use of destructive assignment, which is the epithome of side effects.
Here I'd respond that Ruby provides much more natural support for higher-order functions (because of blocks), its libraries are designed around them. It's actualy hard to avoid using them any time you program in Ruby.
This is not so with Python, whose design is in fact evolving to discourage a functional programming style (Guido has repeatedly rejected adding anonymous closures to the language, and is planning to get rid of built-in functional combinators like map and reduce).
What's non-functional about Ruby? I'd say the biggest thing is the fact that its default sequence datatype is a flexible array type, and not a singly-linked list type.
Yeah, I was reading that a couple weeks ago. Lesson I got out of it (might be wrong, but if it is, it's wrong in a good way): all linear recursion, deep down, boils down to "copying" some recursive "data structure"; scare quotes because you get to pick your own "fake" constructors, destructors and type predicates. Thus, linear recursion boils down to "copying" a "list," and iteration (i.e. tail recusion) boils down to "reversing" a "list."
Some Scheme-ish code might make this clearer. Here's the list copy function in Scheme:
(define (list-copy list)
(if (null? list)
'()
(cons (car list)
(list-copy (cdr list)))))
Pretty straightforward. The null? predicate tests whether its argument is an empty list; car and cdr return the first element of the list and the rest of the list, respectively; cons takes an element and a list, and gives you a new list with that element in front of the old list.
Now take that function, and change it so that instead of using the "real" null?, cons, empty list, car and cdr, we use "fake" ones, that we just pass in as arguments:
(define (fake-list-copy fake-cons fake-empty-list
fake-null? fake-car fake-cdr
fake-list)
(if (fake-null? fake-list)
fake-empty-list
(fake-cons (fake-car fake-list)
(fake-list-copy (fake-cdr fake-list)))))
Now you can write *any* linear recursive function as an application of fake-list-copy. For example, computing the factorial of n. Suppose you had a singly linked list that started with n, and had each subsequent element one less than the previous one, down to 1; for example, for the factorial of 5, that you had the list (5 4 3 2 1). Now, if you use the real null?, car and cdr, but use multiplication and 1 as your fake-cons and fake-empty-list, then (fake-list-copy * 1 null? car cdr '(5 4 3 2 1)) gets you the factorial of 5.
Of course, building those lists is inefficient. But we don't have to build them. We can represent each list as a number:
5 => (5 4 3 2 1)
4 => (4 3 2 1)
...
1 => (1)
0 => () ; the empty list
With that representation, we can choose appropriate functions to use as fake-null?, fake-car and fake-cdr. We use zero? as fake-null?, identity as fake-car (identity just returns its argument without altering it), and decrement as fake-cdr. Thus, the following will compute factorial recursively:
(define (zero? x) (= 0 x))
(define (identity x) x)
(define (-- x) (- x 1))
(define (factorial n) (fake-list-copy * 1 zero? identity -- n))
Of course, doing this recursively takes up stack space. But you can do it without stack space by basing the whole thing on abstracting the definition of a function to reverse lists, instead of one for copying them. That's left as an exercise for the reader...
And of course, after we master all that, just to sound smart, we will thereafter call the fake-list-copy function a "list hylomorphism"...
That shouldn't be called "Avoid Recusion," because you're not really avoiding recursion. What you're doing (as the wiki itself explains) is abstracting it into a higher-order function. Still a pretty damn important technique that one should master in functional languages--recognizing the "shape" of a loop (is it a map? a left or right fold? an unfold?), and implementing the looping logic as a higher-order function separately from its specific uses.