Not only does digital naturally have 1 to 2 zones of added exposure range over 35mm, but scanning any negative with even the best scanner reduces films already inferior exposure range by up to one additional zone!
First, "35mm" is a film size, not a medium. Your statement is meaningless.
As another poster said, digital can't beat the exposure range of negative film, period. Slide film (which I prefer) IIRC gives more contrast than digital, too.
In general, for screen display, digital has a bit of a resolution advantage because scanning film introduces blur. OTOH I like the color reproduction of film way better.
I'm a film guy, but my feeling is that 3:2 is a great proportion for landscape-orientation shots, but not that good for portrait, while 3:4 is the opposite. I usually find myself cropping portrait orientation shots to something close to 3:4, while I crop landscape shots less frequently, and usually to make them narrower and more panoramic.
I think his point is that the fact that it's got the word "digital" in it creates the expectation that the tips are going to be at least a bit specific to digital photography. And they really aren't.
Have you looked at the photography technique section in a bookstore lately? You'll find countless books whose title goes "Digital [insert plain old photography topic]".
The funniest one I've seen is Digital Nude Photography. I guess the difference between this book and one about plain old boring film nudes is that it tells you how to upload the pix to the Usenet or something.
For the first example you give, as it happens, it's possible to determine automatically a partial order in which to execute the statements: you set up a graph saying which statements depend on the results of which others, and you just evaluate them in some order that satisfies this. Sounds like a task for Prolog.
Well, I'm kidding, of course, but it's interesting that the way your beginners are thinking is accommodated by logic programming.
What you want to do is to carry all your gadgets in a diaper bag. Yes, I'm serious. This is a time-tested technique. Nobody wants to steal a baby-blue or pink cute little bag full of shit.
"Correct closest form" on what grounds? Just because you say so?
You used the word "nationalism". The notion of a "nation", classically, is tightly linked to that of "race": a nation is a group of people who share certain characteristics: race, language and a homeland. This linkage hasn't evaporated from the folk usage of the term in the USA: Americans, for example, popularly judge Hispanics to be "non-whites" in general, regardless of actual skin pigmentation.
You're picking nits that don't exist with this "nationalistic discrimination" distinction. "Nation" and "race" are not at all dissociated concepts in US society.
Somebody with the class and educational background to get this sort of job in India speaks English well enough. Your problem is not that the foreign workers speak bad English, but rather that you're intolerant of anybody who speaks it with a foreign accent, and undisposed to listen to them in the first place. (Of course you're not going to understand what somebody says if you don't listen to them.)
And so does B&W mode. The best way to make B&W digital images is to shoot them in color, then mix the RGB channels down to a single channel. By controlling the mix, you can control how colors are mapped to gray levels. Hell, I do this with images scanned from film all the time.
Except that it may take *much longer* to have ref going out of scope after you don't have the need of the object it references.
In good programming style, a function should be short and simple: it should do just one thing, and return. Which means that any references in local scope should cease to exist quickly. If your function allocates objects A, B, C, doing something with them, then allocating D and E, and doing something else with those two, and then returning, you should rewrite that as two functions.
During this time, your program is using more memory than it needs.. This time may be the whole duration of the program if your reference is referenced by a global variable --> memory leak.
Good programming style also avoids the use of global variables. And if one does need such variables, one certainly doesn't stick ephemeral values in them.
Essentially, the scope of a variable is a way of managing the lifetime of the objects it refers to. If you want an object to live forever, you reference it from a variable with a very wide scope. If you want it to live for a very short time, you confine it to a narrow scope. Given these reasonable programming practices, GC can identify objects as soon as they are available for collection.
If you have unneeded objects that can't be collected, you're misscoping references.
Whining about open source software is like complaining about the quality of a Wikipedia article.
The Wikipedians keep bragging about how much better their site is than real encyclopedias. And their "arguments" for this are not based on any actual comparisons of article quality, but rather (a) number of articles (a.k.a. "we got more articles than any real encyclopedia, even if a huge number of them are stubs and/or on topics nobody cares about like anime"); (b) placement in search results (a.k.a. "if Google searches return our articles all the time, it must be because they're good, not because we're effectively spamming the web"); (c) "bazaar" contribution model ("we allow anybody to contribute, and that obviously makes our project superior! No need to compare article quality!"); (d) selective anecdotal evidence ("We looked *really* hard to find a handful errors in Britannica, that Wikipedia doesn't have!"-- pot, kettle, black).
In short, the Wikipedians really deserve to be made major fun of.
I've read that link. I use the channel mixer in the Gimp all the time to make B&W images, so I know perfectly well that it's REALLY clumsy to work with.
A major reason is that the Gimp doesn't have a decent preview feature for filters. If you're using the program's built-in tools (e.g. Levels, Curves, Color Balance, etc.), you can see the effect on the image window as you tweak the controls, scroll the image, zoom in and out, etc. With plugin filters, OTOH, if there's ANY preview it's the plugin that provides a little tiny thumbnail in its dialog. So, if I'm tweaking the balances in the channel mixer, I can't preview the results in detail at all before applying the filter. I need to apply filter, look at and make mental note of results, undo, open up the filter again, readjust, apply, compare to previous results from memory, etc. A decent preview mechanism would fix this.
But even with this improvement, Photoshop would still beat the Gimp, due to adjustment layers. The Gimp is not a bad program at all, but it's just not up to par with PS.
Global variables should be avoided vehemently. At any rate, I will venture the guess that whatever this library does, it should be implemented in terms of a stack, FIFO queue, priority queue, or some other such data structure that imposes a discipline on adding, processing and removing objects.
If there is something bad programmers should be forbidden from authoring, libraries are it.
Unfortunately you can have memory leaks with a GC: what if you are sloppy and don't put some 'ref = 0;' in your program?
When ref goes out of scope, the object it references becomes available for collection. It's that simple.
In fact, your misconceived example negates the whole point of GC-- your ref = 0, in terms of programmer logic, amounts to free(ref), which is exactly what you don't have to do if you have GC!
In this OCaml code, the plusx is created "on the fly" and it is different function, depending on the value of x that is read on runtime.
I'm ready to believe you're simplifying this deliberately to illustrate functional programming techniques, but I think the simplification here is confusing.
It's important to keep in mind the difference between code routines and closures. The term "function" as is commonly used doesn't respect this difference. C's "functions" are code routines, while ocaml's are closures, i.e. a pair of a routine and an invocation frame.
What's being "created on the fly" are closures, which are like stack frames (storage for local values of identifiers in an invocation), but which:
are allocated in the heap,
have a pointer to a "parent" frame (the bindings in the enclosing environment), and
have unlimited extent (since the invocation of a closure A might return a closure B whose "parent" is A, requiring that A be kept around indefinitely after the call to it returns).
I think the point the original poster is making can be expressed in another way, but one that's more revealing of what's at stake: stack allocation is a form of automatic memory management.
In any modern language, there is some form of automatic storage management behind the scenes for function-local storage. Imagine if in C, you had to manually allocate the stack frame of any function you called, and every function had to deallocate its frame before returning. This would be tedious and repetitive. Automatic management of a stack of limited-extent frames provides the programmer a simple (but restricted) way of doing this.
It would be possible to have a functional language where the storage for closures was managed by hand. Imagine a language like C except that it allowed you, when you called a function, to specify a heap-allocated binding to be used in the invocation, instead of a stack frame.
This would be similar to the hypothetical C variant from above, where the programmer was responsible for creating and destroying stack frames. But much harder, since closures have unlimited extent. In the stack allocation case, it's clear when the allocations and deallocations need to happen (before the a function is called, and before one returns). In the manually allocated closure language, the programmer would have to figure out on his own the extent of every closure, and when and where it's safe to free them. This is not simply tedious like in stack allocation, but rather devilishly complex in general.
I happened to have the bad luck to upgrade from a gimp-2.0pre3 built before gnome 2.6 hit the CVS, to a gimp-2.0 final from after gnome 2.6 entered. That was really awful, because the FreeBSD gimp port wouldn't build against the older libs the way you describe.
This is particularly annoying because this is one of the main reasons I switched to BSD from Debian-- with Debian, unless you're running stable, the dependencies for any new binary package you install can cascade up the dependency graph and then back down, so that you need to download and install 150MB worth of upgrades just for one little program. Building ports from source is much better this way-- the port normally will just compile against whatever is in your system. Except when it doesn't, like in this case.
If people can't patent things (like AIDS medication) they will not invent it because they will never recoup their R&D costs if it is to be just given away or "legally pirated".
This is a reasonable argument that runs into a crucial problem, which is that pharmaceutical companies spend more money on marketing and management than they do on R&D.
Sometimes I wonder if much of the pharmaceutical industry should be required to be non-profit. Or maybe the R&D/patent holding part should be split off from the manufacturing/sales part; the first would be required to be non-profit, and sustain itself through a combination of private donations and patent royalties (with compulsive licensing), while the second would be allowed to be for-profit.
(One of the problems is that R&D and manufacturing for drugs are possibly not cleanly separable; part of the research that goes into drugs is how to make them cheaply...)
Africa has easily the most complex localisation problem of any market, with more languages than the rest of the world combined
Not at all. In fact, Asia has more languages than Africa; though the distinction that page makes between "Asia" and "Pacific" is kind of sketchy, since Indonesia and Papua New Guinea are in different categories despite sharing an island...
The same language is used to mark up documents and to write extensions. A Turing-complete markup language with powerful macro-rewriting capabilities is a bad idea-- hard to parse, to start with. Using SGML for markup would be much better.
The language is also pretty crummy for coding extensions. It would be far better if the system just provided an API that one could program to with various languages (I'd prioritize Python here, since it's easy for beginners-- though I'm a Ruby person).
No namespaces. I edited and typeset a multi-author article collection in LaTeX, and one runs into the following problem: each author has their own modified version of the same hand-me-down macros, all of course with the same names; the identifiers in one package are always stepping all over those in another.
To be fair: TeX was designed over 20 years ago, and some of its design decisions hold up really well: the separation of block-based layout (TeX/LaTeX), font technologies (Metafont) and printing/display (xdvi) allows one to plug in new things into the overall system (Postscript and Truetype fonts, PS/PDF generation, etc.)
See for instance the old version of The Great Computer Language Shootout where Haskell is ranked faster than Java.
IIRC, the reason this was so is because, given the test design, Java incurred a very large penalty for each test, from starting up its environment. Once the shootout's implementor figured out a way to factor this out (use a Hello World benchmark to measure startup time), Java's CPU performance shot up very close to the top.
An out-of-date reference book will be organized in roughly the same way as the newer versions. And, for a student I'd think that how they present the information counts more than whether it's the latest information.
Slashdot Mirror
First, "35mm" is a film size, not a medium. Your statement is meaningless.
As another poster said, digital can't beat the exposure range of negative film, period. Slide film (which I prefer) IIRC gives more contrast than digital, too.
In general, for screen display, digital has a bit of a resolution advantage because scanning film introduces blur. OTOH I like the color reproduction of film way better.
I'm a film guy, but my feeling is that 3:2 is a great proportion for landscape-orientation shots, but not that good for portrait, while 3:4 is the opposite. I usually find myself cropping portrait orientation shots to something close to 3:4, while I crop landscape shots less frequently, and usually to make them narrower and more panoramic.
I think his point is that the fact that it's got the word "digital" in it creates the expectation that the tips are going to be at least a bit specific to digital photography. And they really aren't.
Have you looked at the photography technique section in a bookstore lately? You'll find countless books whose title goes "Digital [insert plain old photography topic]". The funniest one I've seen is Digital Nude Photography. I guess the difference between this book and one about plain old boring film nudes is that it tells you how to upload the pix to the Usenet or something.
For the first example you give, as it happens, it's possible to determine automatically a partial order in which to execute the statements: you set up a graph saying which statements depend on the results of which others, and you just evaluate them in some order that satisfies this. Sounds like a task for Prolog. Well, I'm kidding, of course, but it's interesting that the way your beginners are thinking is accommodated by logic programming.
What you want to do is to carry all your gadgets in a diaper bag. Yes, I'm serious. This is a time-tested technique. Nobody wants to steal a baby-blue or pink cute little bag full of shit.
You used the word "nationalism". The notion of a "nation", classically, is tightly linked to that of "race": a nation is a group of people who share certain characteristics: race, language and a homeland. This linkage hasn't evaporated from the folk usage of the term in the USA: Americans, for example, popularly judge Hispanics to be "non-whites" in general, regardless of actual skin pigmentation.
You're picking nits that don't exist with this "nationalistic discrimination" distinction. "Nation" and "race" are not at all dissociated concepts in US society.
Who is the first racist that will make jokes about outsourced tech jobs?
Somebody with the class and educational background to get this sort of job in India speaks English well enough. Your problem is not that the foreign workers speak bad English, but rather that you're intolerant of anybody who speaks it with a foreign accent, and undisposed to listen to them in the first place. (Of course you're not going to understand what somebody says if you don't listen to them.)
And so does B&W mode. The best way to make B&W digital images is to shoot them in color, then mix the RGB channels down to a single channel. By controlling the mix, you can control how colors are mapped to gray levels. Hell, I do this with images scanned from film all the time.
In good programming style, a function should be short and simple: it should do just one thing, and return. Which means that any references in local scope should cease to exist quickly. If your function allocates objects A, B, C, doing something with them, then allocating D and E, and doing something else with those two, and then returning, you should rewrite that as two functions.
During this time, your program is using more memory than it needs.. This time may be the whole duration of the program if your reference is referenced by a global variable --> memory leak.
Good programming style also avoids the use of global variables. And if one does need such variables, one certainly doesn't stick ephemeral values in them.
Essentially, the scope of a variable is a way of managing the lifetime of the objects it refers to. If you want an object to live forever, you reference it from a variable with a very wide scope. If you want it to live for a very short time, you confine it to a narrow scope. Given these reasonable programming practices, GC can identify objects as soon as they are available for collection.
If you have unneeded objects that can't be collected, you're misscoping references.
The Wikipedians keep bragging about how much better their site is than real encyclopedias. And their "arguments" for this are not based on any actual comparisons of article quality, but rather (a) number of articles (a.k.a. "we got more articles than any real encyclopedia, even if a huge number of them are stubs and/or on topics nobody cares about like anime"); (b) placement in search results (a.k.a. "if Google searches return our articles all the time, it must be because they're good, not because we're effectively spamming the web"); (c) "bazaar" contribution model ("we allow anybody to contribute, and that obviously makes our project superior! No need to compare article quality!"); (d) selective anecdotal evidence ("We looked *really* hard to find a handful errors in Britannica, that Wikipedia doesn't have!"-- pot, kettle, black).
In short, the Wikipedians really deserve to be made major fun of.
A major reason is that the Gimp doesn't have a decent preview feature for filters. If you're using the program's built-in tools (e.g. Levels, Curves, Color Balance, etc.), you can see the effect on the image window as you tweak the controls, scroll the image, zoom in and out, etc. With plugin filters, OTOH, if there's ANY preview it's the plugin that provides a little tiny thumbnail in its dialog. So, if I'm tweaking the balances in the channel mixer, I can't preview the results in detail at all before applying the filter. I need to apply filter, look at and make mental note of results, undo, open up the filter again, readjust, apply, compare to previous results from memory, etc. A decent preview mechanism would fix this.
But even with this improvement, Photoshop would still beat the Gimp, due to adjustment layers. The Gimp is not a bad program at all, but it's just not up to par with PS.
If there is something bad programmers should be forbidden from authoring, libraries are it.
When ref goes out of scope, the object it references becomes available for collection. It's that simple.
In fact, your misconceived example negates the whole point of GC-- your ref = 0, in terms of programmer logic, amounts to free(ref), which is exactly what you don't have to do if you have GC!
I'm ready to believe you're simplifying this deliberately to illustrate functional programming techniques, but I think the simplification here is confusing.
It's important to keep in mind the difference between code routines and closures. The term "function" as is commonly used doesn't respect this difference. C's "functions" are code routines, while ocaml's are closures, i.e. a pair of a routine and an invocation frame.
What's being "created on the fly" are closures, which are like stack frames (storage for local values of identifiers in an invocation), but which:
- are allocated in the heap,
- have a pointer to a "parent" frame (the bindings in the enclosing environment), and
- have unlimited extent (since the invocation of a closure A might return a closure B whose "parent" is A, requiring that A be kept around indefinitely after the call to it returns).
I think the point the original poster is making can be expressed in another way, but one that's more revealing of what's at stake: stack allocation is a form of automatic memory management.In any modern language, there is some form of automatic storage management behind the scenes for function-local storage. Imagine if in C, you had to manually allocate the stack frame of any function you called, and every function had to deallocate its frame before returning. This would be tedious and repetitive. Automatic management of a stack of limited-extent frames provides the programmer a simple (but restricted) way of doing this.
It would be possible to have a functional language where the storage for closures was managed by hand. Imagine a language like C except that it allowed you, when you called a function, to specify a heap-allocated binding to be used in the invocation, instead of a stack frame.
This would be similar to the hypothetical C variant from above, where the programmer was responsible for creating and destroying stack frames. But much harder, since closures have unlimited extent. In the stack allocation case, it's clear when the allocations and deallocations need to happen (before the a function is called, and before one returns). In the manually allocated closure language, the programmer would have to figure out on his own the extent of every closure, and when and where it's safe to free them. This is not simply tedious like in stack allocation, but rather devilishly complex in general.
So, garbage collection solves it.
This is particularly annoying because this is one of the main reasons I switched to BSD from Debian-- with Debian, unless you're running stable, the dependencies for any new binary package you install can cascade up the dependency graph and then back down, so that you need to download and install 150MB worth of upgrades just for one little program. Building ports from source is much better this way-- the port normally will just compile against whatever is in your system. Except when it doesn't, like in this case.
This is a reasonable argument that runs into a crucial problem, which is that pharmaceutical companies spend more money on marketing and management than they do on R&D.
Sometimes I wonder if much of the pharmaceutical industry should be required to be non-profit. Or maybe the R&D/patent holding part should be split off from the manufacturing/sales part; the first would be required to be non-profit, and sustain itself through a combination of private donations and patent royalties (with compulsive licensing), while the second would be allowed to be for-profit.
(One of the problems is that R&D and manufacturing for drugs are possibly not cleanly separable; part of the research that goes into drugs is how to make them cheaply...)
Not at all. In fact, Asia has more languages than Africa; though the distinction that page makes between "Asia" and "Pacific" is kind of sketchy, since Indonesia and Papua New Guinea are in different categories despite sharing an island...
- The same language is used to mark up documents and to write extensions. A Turing-complete markup language with powerful macro-rewriting capabilities is a bad idea-- hard to parse, to start with. Using SGML for markup would be much better.
- The language is also pretty crummy for coding extensions. It would be far better if the system just provided an API that one could program to with various languages (I'd prioritize Python here, since it's easy for beginners-- though I'm a Ruby person).
- No namespaces. I edited and typeset a multi-author article collection in LaTeX, and one runs into the following problem: each author has their own modified version of the same hand-me-down macros, all of course with the same names; the identifiers in one package are always stepping all over those in another.
To be fair: TeX was designed over 20 years ago, and some of its design decisions hold up really well: the separation of block-based layout (TeX/LaTeX), font technologies (Metafont) and printing/display (xdvi) allows one to plug in new things into the overall system (Postscript and Truetype fonts, PS/PDF generation, etc.)IIRC, the reason this was so is because, given the test design, Java incurred a very large penalty for each test, from starting up its environment. Once the shootout's implementor figured out a way to factor this out (use a Hello World benchmark to measure startup time), Java's CPU performance shot up very close to the top.
It doesn't explain why you presume its relevance by actually telling it.
Anecdote.
An out-of-date reference book will be organized in roughly the same way as the newer versions. And, for a student I'd think that how they present the information counts more than whether it's the latest information.