Here in Hong Kong we are inundated with a series of inane "public service announcements" that beggar belief. One classic warned people against throwing waste out the window of apartment buildings... showing a "careless" person throwing a televison out the window on unsuspecitng children.
Here in Canada my sister lent her car to her daughter overnight. I said "Why in the world did you do that?" Sure enough, next day it came back with a big dent in it - some idiot had thrown a TV out the window as a joke.
This is after the car had collected a few other dings from being borrowed for a day or two - like turning right from the left lane (What do you mean left lane - there's only one lane there... isn't there" No, its 2 lanes each way, and you pushed the other car onto the sidewalk).
And the post office truck with the bad parking brake that banged up one side, while nobody was in either vehicle...
And the russians who spoke no english, ran a red light and hit the same side...
There's a few I've missed... but you get the idea. TVs out windows happen, just like other weird sh*t.
Actually, its there so that hunters don't mistake them for live prey and unload their 30-30s on them. Hunters are dumb. They saw a sign that said that lettuce was "in season" and figured it was ok to shoot up the vegetable stand. During deer season, they shoot countless farm tractors just because they say "John Deere" on them. They shoot stop signs. Now there's a hard target to hit - a stopped stop sign! They have to wear funny orange vests so other hunters won't go "Gee, that guy might look pretty good strapped on the roof of my pickup." Dick ("blast yer face off") Cheney is a hunter. It was the other guy's fault for not wearing day-glo face paint!
Simple solution - print the warning labels under the cup, along with a label prominently on the side saying where the warnings are. This way, they have to empty the cup to read the labels. Didn't empty the cup first to read all the warnings before drinking? Too bad - negligence on your part.
Simpler solution - don't serve crap coffee in crap paper cups. And don't use your lap as a coffee-cup holder, because it could end up as a coffee-sans-cup-holder.
who cares if it doesn't do what it was intended for originally if it can be useful for something else?
... like all the coke snorters who use Preparation H to "reduce the painful irritation and swelling" of the sensitive tissues in their noses.
True story - when the Hell's Angels started a chapter in Trois-Rivieres, sales of Preparation H tripled, all due to the increase in the local coke trade.
That's why I use my house keys. Gets in, gives the old ear canal a good scraping, gets rid of any ear wax without leaving behind any lint, and it feels SOOOoooo goooOOOoooood!
Changing the subject? The article was asking the best way to build a text-beased ui app. Not enough info is given (type of data presented to user, range of responses required from user, deployment, hardware, user base, server options, etc.) for anyone to be able to state "ncurses is THE solution."
Heck, for all we know, they're using dumb terminals that have zero cursor control - you have to draw the screen strictly a line at a time, wait for the user to respond, then scroll everything out of the way and start over.
Ncurses isn't necessarily the right tool, but only the person who originally posted the question is in a position to decide whether they want/need ncurses. Using ansi escape sequences might be the best scenario. I'm not saying it is, but that it should be considered, instead of just "ncurses is the one true way", because it quite simply isn't.
Its the same with java - I've always made fun of its slowness, wordiness, bloatedness, etc., but I'm still recommending we use it at work for one particular application where neither c nor a scripting language are appropriate.
All I'm saying is that without enough information, why not look at ALL the possibilities? Since the poster was an "ask slashdot", and indicated that they originally wanted to do this as a web app that could be accessed through links/lynx to accomodate the "low bandwidth" scenario, and that was nixed, we can't assume much in the way of writing code for environments outside of the web... maybe little or no c/c++, for example - but their first hurdle may be the server, not the client.
We can't even assume they're using multi-port serial cards... or terminals. So lets make a few assumptions - that they're going to be running this on a beige box, that they're in fact using a multi-port serial breakout box, and that the clients are either smart terminals or pcs running a terminal emulator.
"bandwidth-constrained" today doesn't mean the same as "bandwidth-constrained" a couple of decades ago. Without knowing what the requirements are, its impossible to say if ncurses is the best way to go.
As for the terminals themselves, one of the places I worked at just bought them used by the pallette for $25, and they all "spoke ansi". Places were throwing them in the dumpster because nobody wanted them.
As for the speed of the microprocessor, if they're still stuck with the green screens, they would probably be better off picking up a few junk laptops and using them as their "smart terminals". Any old 286, 386 or 486 would do - you can find used 486s for next to nothing. They won't even need a hard drive or battery - just power them up from a wall wart, boot them off a floppy or cd and run the terminal software from the same media.
After all, how much can a used laptop with a bad hard drive and no battery cost?
The best part - they'll have a serial port on the back that's good for 33.6 (and if its at least a 486, probably up to 115k, though I've had trouble with long cable runs at anything over 33.6).
One sequence of events:
server sends client a screen with fields to fill in, etc.
at every keypress, client sends keypress back to server to be processed
server processes keypress, sends back screen updates
The end result will be slow and ugly.
If some smarts are embedded in the client program (the screens, the local key handling, cursor control, etc)...
Client software generates screen
User inputs data - client software does all screen handling
On completion, client software sends data to server, and waits for response codes
goto 1
A lot less traffic between the client and server, and screen control is handled completely locally. Of course, this means running the client on a pc, not a terminal...
Without enough info, we can't make a rational decision, so we should consider all the possibilities...
The lumen ratings of all cf bulbs give their initial brightness... an initial brightness that degrades quite quickly. They're crap.
And, as my figures show, at 7 cents a kw/h, incandescents cost less than half, by the time you include the cost of the bulbs you proposed.
At 20 cents an hour, its about break-even. However, for those of us in northerly climes, you have to factor in the value of the heat generated by incandescents during the winter, so the break-even point is further shifted, to 30 cents per kw/h. Below that, CF bulbs are a waste of money.
Better to buy REAL flourescents... except that even a two-tube unit is going to consume 80 watts...
The light fixture in the kitchen is a 3-bulb unit, so there was no "put in extra lamps" issue. It was a question of which gives more light, the "equivalent to 100 watt" cf bulbs, or the 60-watt incandescents. The 60-watt incandescents win. Also, I can use the dimmer with them, which can reduce their consumption to well below the "equivalent to 100 watt" cf bulbs, as required.
CF bulbs might make sense in some areas - for example, lights that are on all the time and you don't care about the light quality, you just want any type of light (infrequently used stairwells, for example).
They don't make sense in other uses. My kitchen is one of them. Both in terms of overall cost (bulbs + electricity) and the desired lighting levels, the incandescents win for that particular application. As always, YMMV, but CF bulbs aren't there yet.
I guess that the +5 Interesting means a lot of us are stooopid because we don't automatically assume that ncurses is the "only solution".
Ncurses may be the "swiss army knife" of text-mode interfaces, but not every job calls for a swiss army knife. The K.I.S.S. formula works fine for many of us. I'd rather cut my steak with a single-purpose steak knife than a swiss army knife. Similarly, automatically assuming that ncurses is the best/only realistic option is simplistic.
found it to be a wonderful abstraction layer to send the funky escape sequences for me rather than trying to figure them out on my own.
??? WTF? The ansi escape sequences can be "learned" in 10 minutes. They're really, really simple. Simple as in "you can do it with just a text editor, and then cat the file to the screen and see the results." No compiling. No executable files. Simpler than html, in fact. If you couldn't take 10 minutes to figure them out, that says more about you than about which tool is right for the job...
"Those who don't know ncurses are doomed to reinvent it, badly."
unlike you, I've used ncurses. It isn't needed in many cases, and is not just overkill, but the wrong tool for the job.
Using ncurses when you don't need to is dumb.
Yes, of course, but it's fairly clear that this is the ideal use case for ncurses.
Quite the contrary, it isn't clear at all. Do you have the design specs? The use cases? The different modes of operation? Didn't think so.
Adding complexity for the sake of complexity doesn't make sense.
Again, does not apply. ncurses is actually quite elegant, and well thought-out. It's adding complexity for the sake of portability across terminals, speed (ncurses optimizes escape codes far better than most programmers who do it by hand), and abstraction (a lot of the terminals in the field aren't ANSI.)
Ncurses is butt-ugly. and btw, while a lot of terminals aren't just "ansi", they speak ansi. Also, even totally unoptimized ansi runs fine on 19.2k multi-port serial connections.
Avoiding ncurses means avoiding event loops, callbacks, etc.
Yes, and this is a good thing how?
Clearer operating modes, fewer bugs. That's always a good thing.
That would be nice and all except that their particular terminal probably doesn't speak ANSI terminal codes. Just because it's ANSI doesn't mean it's used everywhere. In fact, I doubt ANSI is used in even a MAJORITY of the serial terminals still in use today.
You don't need to use extended features like "screen protect" - have your app figure out how to update the screen accordingly and you're good, and you now have "screen protect" for all terminals.
Even a 20-year-old green-screen terminal works fine with plain ansi sequences - I know, I've had to use them (the company would buy old ones by the palette for $25 and put them into service as units died out. At $1 - $2/terminal, it wasn't worth the hassle of buying new ones).
You'd set it into raw input on the client side, obviousy - but you can do that by issuing the proper escape sequences in a script.
There's also a ton of code around for doing tty form handling utside of ncurses. try typing "dialog" at the command prompt. It creates dialog boxes to be displayed from shell scripts.
Sample code: dialog --msgbox "hello, world!" 5 40
If you want to see the output, type : dialog --msgbox "hello, world!" 5 40 > output.txt
You'll have to press enter twice (the console is waiting for your input).
Then use any editor to see the output - a bunch of ansi escape sequences:
Their terminals will work just fine with ansi escape codes - wtf do you thing ncurses sends it? Magic pixie dust?
Using ncurses when you don't need to is dumb. Adding complexity for the sake of complexity doesn't make sense.
Avoiding ncurses means avoiding event loops, callbacks, etc.
Or have you ever even used it? Because from your post, its obvious you don't know much about when it comes to terminals.
I've written terminal apps (with their own serial-port drivers), and it was easy to write my own screen-handling routines. Any half-competent c programmer should be able to do the same.
And you will then discover some of the reasons why you should have used ncurses in the first place:
1. Does the cursor jump to the next line when you hit the 80th column?
Only if your terminal window is 80 columns wide. Of course, if you want it to no matter what the actual width, just insert a newline at col80...
2. If you type a character in the lower right corner, does it scroll up the screen?
Only if you haven't first set the terminal to raw input...
3. Are they going to bring in some non-ansi terminals and expect you to make them all work?
Just try to find a terminal that doesn't support the standard ansi escape codes... they may add extra functionality built upon it, but you can safely ignore that by sticking to the base escape codes.
4. Which subset of the ansi sequences are going to be available? Using xterm, gnome-terminal, putty, ansi.sys,...? Which version? They all support different subsets/extensions of the "standard", and have different bugs.
So just use the bog-standard ansi sequences.
5. What other intresting "bugs" in all the possible terminals do you need to work around?
As I said, by sticking with the standard escape sequences, you don't have to worry about all the "extensions" each different terminal supports. No need to bother with the terminfo database, etc.
why bother with conio (console i/o - a borland c / turbo c library) when you can just write the raw ansi sequences to the screen? They're really easy, and you can even prototype your interface with nothing more than a text editor (vi or notepad) and "playing" it to your terminal ("type 'filename'" in dos, "cat 'filename'" in linux).
You can clear the screen, home the cursor, more the cursor to specific coordinates, erase to the end of a line, change foreground and background colors, even have web 1.0-style blinking text.
Just remember that you have to send sequences to set your terminal into raw mode if you don't want line-buffered keyboard input.
Incandescets definitely suffer degredation as the tungsten filament "evaporates" and recondenses on the inside of the bulb. Still, by paying maybe 50 cents more to buy a good quality bulb (not those 10,000 hour or "extended life" bulbs) you get decent light output on the cheap, and you can afford to toss them every year.
WalMart is pushing the CFs for the same reason that every other store is - there's a nice profit in them, because almost nobody ever buys just one pack.
Those torch lamps are energy guzzlers, and they get HOT. Want to start an "accidental" fire fast - they're the way to go.
One thing to look out for is that a lot of the CF bulbs can't be installed "upside down" or in an enclosed globe - the heat damages the starter in the base.
Oh, and here's one situation where you get _more_ light out of CF bulbs: In fixtures with low wattage limits. If you have a lamp rated for maximum 65 watts, you can put CF bulbs in that make huge amounts of light for less than that 65 watts.
Not so... the CF bulbs lose their initial output rther quickly, so any initial brightness advantage is lost.
I replaced the 3 60-watt incandescent bulbs in the kitchen with 3 "equivalent to 100 watt" cf bulbs. It was a LOT brighter - for about a month. After a few months, it was dimmer than the old incandescents, to the point that I at first thought there might be something wrong with my eyes. Then I thought - "maybe dust?" - but washing them made no difference. Those "equivalent to 100 watt" CF lights were worse than 40 watt incandescents after less than a year.
I moved a month ago, and replaced the 3 incandescents in the new kitchen with new "latest generation equivalent to 100 watt" CF bulbs. Same story. The 60-watt incandescents are back. Better quality, brighter light. Plus, they work fine with dimmer switches to save energy.
So I'm sitting on a couple of dozen CF bulbs, some hardly used, that have been replaced with incandescent bubls; the technology isn't there yet, despite the hype.
My guess is that people just don't notice the dimming over time, like a frog in a slowly-warming bucket.
No they're not. Their light output falls off very quickly - within the first week or so, same as other flourescents. Then it slowly dims further for a long time before it gets to the point where you replace them because "gee, its so dim in here".
That's why many retailers replace their tube flourescents annually - it makes a BIG difference.
Comparing a new CF bulb's output against the worst-case incandescent is dishonest marketing.
I've just changed a bunch of them back to incandescent.
They don't give out "the same amount of light for 75% less" - its more like 75% light for 50% less. I tried various makes, and the ones that claimed to be the equivalent of a 100 watt incandescent were more like 60 watts. The worst were the trilights - spending $25 on a couple of bulbs that are useless galls me no end. So I'm sitting on a couple of hundred dollars (I had changed all the lights) of CFs that are going to end up as dust collectors.
Buy better-quality incandescents - they give more lumens per watt than the cheap incandescents (you can check the lumens output on the box). And avoid those "long life" incandescents - they achieve their long life by being VERY inefficient. CFs don't save money if you have to use twice as many to get the same light output.
Slashdot Mirror
Here in Canada my sister lent her car to her daughter overnight. I said "Why in the world did you do that?" Sure enough, next day it came back with a big dent in it - some idiot had thrown a TV out the window as a joke.
This is after the car had collected a few other dings from being borrowed for a day or two - like turning right from the left lane (What do you mean left lane - there's only one lane there ... isn't there" No, its 2 lanes each way, and you pushed the other car onto the sidewalk).
And the post office truck with the bad parking brake that banged up one side, while nobody was in either vehicle ...
And the russians who spoke no english, ran a red light and hit the same side ...
There's a few I've missed ... but you get the idea. TVs out windows happen, just like other weird sh*t.
Actually, its there so that hunters don't mistake them for live prey and unload their 30-30s on them. Hunters are dumb. They saw a sign that said that lettuce was "in season" and figured it was ok to shoot up the vegetable stand. During deer season, they shoot countless farm tractors just because they say "John Deere" on them. They shoot stop signs. Now there's a hard target to hit - a stopped stop sign! They have to wear funny orange vests so other hunters won't go "Gee, that guy might look pretty good strapped on the roof of my pickup." Dick ("blast yer face off") Cheney is a hunter. It was the other guy's fault for not wearing day-glo face paint!
Simple solution - print the warning labels under the cup, along with a label prominently on the side saying where the warnings are. This way, they have to empty the cup to read the labels. Didn't empty the cup first to read all the warnings before drinking? Too bad - negligence on your part.
Simpler solution - don't serve crap coffee in crap paper cups. And don't use your lap as a coffee-cup holder, because it could end up as a coffee-sans-cup-holder.
Warning: FLAMMABLE. http://www.answers.com/flammable
Warning: INFLAMMABLE. http://www.answers.com/inflammable
So, just to cya, WARNING: INFLAMMABLE FLAMMABLE. or should that be WARNING: FLAMMABLE INFLAMMABLE?
True story - when the Hell's Angels started a chapter in Trois-Rivieres, sales of Preparation H tripled, all due to the increase in the local coke trade.
That's why I use my house keys. Gets in, gives the old ear canal a good scraping, gets rid of any ear wax without leaving behind any lint, and it feels SOOOoooo goooOOOoooood!
Who said anything about it being from their bladder ...?
Changing the subject? The article was asking the best way to build a text-beased ui app. Not enough info is given (type of data presented to user, range of responses required from user, deployment, hardware, user base, server options, etc.) for anyone to be able to state "ncurses is THE solution."
Heck, for all we know, they're using dumb terminals that have zero cursor control - you have to draw the screen strictly a line at a time, wait for the user to respond, then scroll everything out of the way and start over.
Ncurses isn't necessarily the right tool, but only the person who originally posted the question is in a position to decide whether they want/need ncurses. Using ansi escape sequences might be the best scenario. I'm not saying it is, but that it should be considered, instead of just "ncurses is the one true way", because it quite simply isn't.
Its the same with java - I've always made fun of its slowness, wordiness, bloatedness, etc., but I'm still recommending we use it at work for one particular application where neither c nor a scripting language are appropriate.
Something to think about ...?
All I'm saying is that without enough information, why not look at ALL the possibilities? Since the poster was an "ask slashdot", and indicated that they originally wanted to do this as a web app that could be accessed through links/lynx to accomodate the "low bandwidth" scenario, and that was nixed, we can't assume much in the way of writing code for environments outside of the web ... maybe little or no c/c++, for example - but their first hurdle may be the server, not the client.
We can't even assume they're using multi-port serial cards ... or terminals. So lets make a few assumptions - that they're going to be running this on a beige box, that they're in fact using a multi-port serial breakout box, and that the clients are either smart terminals or pcs running a terminal emulator.
"bandwidth-constrained" today doesn't mean the same as "bandwidth-constrained" a couple of decades ago. Without knowing what the requirements are, its impossible to say if ncurses is the best way to go.
As for the terminals themselves, one of the places I worked at just bought them used by the pallette for $25, and they all "spoke ansi". Places were throwing them in the dumpster because nobody wanted them.
As for the speed of the microprocessor, if they're still stuck with the green screens, they would probably be better off picking up a few junk laptops and using them as their "smart terminals". Any old 286, 386 or 486 would do - you can find used 486s for next to nothing. They won't even need a hard drive or battery - just power them up from a wall wart, boot them off a floppy or cd and run the terminal software from the same media.
After all, how much can a used laptop with a bad hard drive and no battery cost?
The best part - they'll have a serial port on the back that's good for 33.6 (and if its at least a 486, probably up to 115k, though I've had trouble with long cable runs at anything over 33.6).
One sequence of events:
- server sends client a screen with fields to fill in, etc.
- at every keypress, client sends keypress back to server to be processed
- server processes keypress, sends back screen updates
The end result will be slow and ugly.If some smarts are embedded in the client program (the screens, the local key handling, cursor control, etc) ...
A lot less traffic between the client and server, and screen control is handled completely locally. Of course, this means running the client on a pc, not a terminal ...
Without enough info, we can't make a rational decision, so we should consider all the possibilities ...
The lumen ratings of all cf bulbs give their initial brightness ... an initial brightness that degrades quite quickly. They're crap.
And, as my figures show, at 7 cents a kw/h, incandescents cost less than half, by the time you include the cost of the bulbs you proposed.
At 20 cents an hour, its about break-even. However, for those of us in northerly climes, you have to factor in the value of the heat generated by incandescents during the winter, so the break-even point is further shifted, to 30 cents per kw/h. Below that, CF bulbs are a waste of money.
Better to buy REAL flourescents ... except that even a two-tube unit is going to consume 80 watts ...
The light fixture in the kitchen is a 3-bulb unit, so there was no "put in extra lamps" issue. It was a question of which gives more light, the "equivalent to 100 watt" cf bulbs, or the 60-watt incandescents. The 60-watt incandescents win. Also, I can use the dimmer with them, which can reduce their consumption to well below the "equivalent to 100 watt" cf bulbs, as required.
CF bulbs might make sense in some areas - for example, lights that are on all the time and you don't care about the light quality, you just want any type of light (infrequently used stairwells, for example).
They don't make sense in other uses. My kitchen is one of them. Both in terms of overall cost (bulbs + electricity) and the desired lighting levels, the incandescents win for that particular application. As always, YMMV, but CF bulbs aren't there yet.
You wrote:
However, you seem to forget that you're the one who started with the insults when you wrote this:
I guess that the +5 Interesting means a lot of us are stooopid because we don't automatically assume that ncurses is the "only solution".
Ncurses may be the "swiss army knife" of text-mode interfaces, but not every job calls for a swiss army knife. The K.I.S.S. formula works fine for many of us. I'd rather cut my steak with a single-purpose steak knife than a swiss army knife. Similarly, automatically assuming that ncurses is the best/only realistic option is simplistic.
??? WTF? The ansi escape sequences can be "learned" in 10 minutes. They're really, really simple. Simple as in "you can do it with just a text editor, and then cat the file to the screen and see the results." No compiling. No executable files. Simpler than html, in fact. If you couldn't take 10 minutes to figure them out, that says more about you than about which tool is right for the jobunlike you, I've used ncurses. It isn't needed in many cases, and is not just overkill, but the wrong tool for the job.
Quite the contrary, it isn't clear at all. Do you have the design specs? The use cases? The different modes of operation? Didn't think so.
Ncurses is butt-ugly. and btw, while a lot of terminals aren't just "ansi", they speak ansi. Also, even totally unoptimized ansi runs fine on 19.2k multi-port serial connections.
Clearer operating modes, fewer bugs. That's always a good thing.
Wanna bet?
You don't need to use extended features like "screen protect" - have your app figure out how to update the screen accordingly and you're good, and you now have "screen protect" for all terminals.
Even a 20-year-old green-screen terminal works fine with plain ansi sequences - I know, I've had to use them (the company would buy old ones by the palette for $25 and put them into service as units died out. At $1 - $2/terminal, it wasn't worth the hassle of buying new ones).
You'd set it into raw input on the client side, obviousy - but you can do that by issuing the proper escape sequences in a script.
There's also a ton of code around for doing tty form handling utside of ncurses. try typing "dialog" at the command prompt. It creates dialog boxes to be displayed from shell scripts.
Sample code: dialog --msgbox "hello, world!" 5 40
If you want to see the output, type : dialog --msgbox "hello, world!" 5 40 > output.txt
You'll have to press enter twice (the console is waiting for your input).
Then use any editor to see the output - a bunch of ansi escape sequences:
Their terminals will work just fine with ansi escape codes - wtf do you thing ncurses sends it? Magic pixie dust?
Using ncurses when you don't need to is dumb. Adding complexity for the sake of complexity doesn't make sense.
Avoiding ncurses means avoiding event loops, callbacks, etc.
Or have you ever even used it? Because from your post, its obvious you don't know much about when it comes to terminals.
I've written terminal apps (with their own serial-port drivers), and it was easy to write my own screen-handling routines. Any half-competent c programmer should be able to do the same.
Only if your terminal window is 80 columns wide. Of course, if you want it to no matter what the actual width, just insert a newline at col80 ...
Only if you haven't first set the terminal to raw input ...
Just try to find a terminal that doesn't support the standard ansi escape codes ... they may add extra functionality built upon it, but you can safely ignore that by sticking to the base escape codes.
So just use the bog-standard ansi sequences.
As I said, by sticking with the standard escape sequences, you don't have to worry about all the "extensions" each different terminal supports. No need to bother with the terminfo database, etc.
why bother with conio (console i/o - a borland c / turbo c library) when you can just write the raw ansi sequences to the screen? They're really easy, and you can even prototype your interface with nothing more than a text editor (vi or notepad) and "playing" it to your terminal ("type 'filename'" in dos, "cat 'filename'" in linux).
http://www.dee.ufcg.edu.br/~rrbrandt/tools/ansi.ht ml ansi escape sequences.
You can clear the screen, home the cursor, more the cursor to specific coordinates, erase to the end of a line, change foreground and background colors, even have web 1.0-style blinking text.
Just remember that you have to send sequences to set your terminal into raw mode if you don't want line-buffered keyboard input.
Just write ansi escape sequences to the screen, same as back in the good ole days of writing bbs software.
The article title has nothing to do with the article contents.
... the title is "Which Text-Based UI Do Yo Code With" - not "Which Text-Based UI Library Do You Write To/Compile Against".
I can replace the bulb with a new high-output incandescent every 1000 hours (not very likely) and STILL end up with more money in my pocket...
Incandescets definitely suffer degredation as the tungsten filament "evaporates" and recondenses on the inside of the bulb. Still, by paying maybe 50 cents more to buy a good quality bulb (not those 10,000 hour or "extended life" bulbs) you get decent light output on the cheap, and you can afford to toss them every year.
WalMart is pushing the CFs for the same reason that every other store is - there's a nice profit in them, because almost nobody ever buys just one pack.
Those torch lamps are energy guzzlers, and they get HOT. Want to start an "accidental" fire fast - they're the way to go.
One thing to look out for is that a lot of the CF bulbs can't be installed "upside down" or in an enclosed globe - the heat damages the starter in the base.
I replaced the 3 60-watt incandescent bulbs in the kitchen with 3 "equivalent to 100 watt" cf bulbs. It was a LOT brighter - for about a month. After a few months, it was dimmer than the old incandescents, to the point that I at first thought there might be something wrong with my eyes. Then I thought - "maybe dust?" - but washing them made no difference. Those "equivalent to 100 watt" CF lights were worse than 40 watt incandescents after less than a year.
I moved a month ago, and replaced the 3 incandescents in the new kitchen with new "latest generation equivalent to 100 watt" CF bulbs. Same story. The 60-watt incandescents are back. Better quality, brighter light. Plus, they work fine with dimmer switches to save energy.
So I'm sitting on a couple of dozen CF bulbs, some hardly used, that have been replaced with incandescent bubls; the technology isn't there yet, despite the hype.
My guess is that people just don't notice the dimming over time, like a frog in a slowly-warming bucket.
That's why many retailers replace their tube flourescents annually - it makes a BIG difference.
Comparing a new CF bulb's output against the worst-case incandescent is dishonest marketing.
I've just changed a bunch of them back to incandescent.
They don't give out "the same amount of light for 75% less" - its more like 75% light for 50% less. I tried various makes, and the ones that claimed to be the equivalent of a 100 watt incandescent were more like 60 watts. The worst were the trilights - spending $25 on a couple of bulbs that are useless galls me no end. So I'm sitting on a couple of hundred dollars (I had changed all the lights) of CFs that are going to end up as dust collectors.
Buy better-quality incandescents - they give more lumens per watt than the cheap incandescents (you can check the lumens output on the box). And avoid those "long life" incandescents - they achieve their long life by being VERY inefficient. CFs don't save money if you have to use twice as many to get the same light output.