Is this a synchronous machine or an induction motor? (I ask because "brushless" usually refers to synchronous machines). I had thought that the Tesla used an induction motor (hence the name)... Does it actually use a synchronous motor?
permanent magnet, etc. They don't always peak at intuitive spots.
Yep. Though the permanent-magnet one pretty much does behave like the simple DC motor from physics 101. Also the shunt wound, if you have the luxury of separate field and armature current supplies.
there is very little reason to use a DC motor outside of household applications.
Well... except permanent-magnet brushless DC motors (almost identical to AC synchronous motors) -- which are pretty much the best motors you can have. And their performance is basically that of the theoretical DC motor!
This isn't the issue. It's true that high rotation speeds are a problem in mechanical systems, but a car axle doesn't reach those speeds. Suppose a wheel has a radius of 1.25 ft (an underestimate), and that the car is traveling at a top speed of 200 mph. This gives a rotational speed of 2240 RPM. For comparison, an automotive engine might have a redline (max crankshaft speed) around 6000 RPM. The point is that 2000 RPM is not a particularly scary angular velocity.
Gearboxes are really for converting torque to rotation.[...]Mind you as well that electric motors have bags ans bags more of torque than IC engines...
All true. Electric motors are way more ideal for turning wheels than IC engines. Still, you do need a gearbox (even if it's just the 2-speed one this car has).
Consider two extreme approaches to electric motor sizing for a car:
1 - Choose a motor torquey enough that you don't need gears. Such a motor will either (1) draw an insane current, or (2) have very many windings. Of the two, #2 is more efficient, as torque increases linearly with either the number of windings or the current, whereas resistive power loss increases only linearly with # of windings and quadratically with current.
2 - Choose a motor that can run at a high enough top-end speed without gears. Such a motor will either (1) require an insane voltage, or (2) have very few windings. Of the two, #2 is preferable, as #1 will cause the insulation on the coils to break down. Additionally, #1 keeps weight down.
You see that the requirements of situation 1 and situation 2 are mutually exclusive. Hence, we choose a compromise. Unfortunately, when we do this what we end up with is a motor which either can't handle the low end, can't handle the high end, or both -- so we need gearing to deal with that, and keep the motor running in its most efficient range.
Luckily, this efficient range is much wider than that for an IC engine, so the gearbox can be smaller, lighter*, and more efficient than that for a gasoline-engine car.
(* but don't think electric cars are lighter: they're not. The weight of the motor (which is basically a big chunk of intricately-arranged copper) usually more than offsets these other savings; electric cars are heavier. That said, the electric motor's greater torque offsets the increased mass, so if you're just considering acceleration, the electric car handily wins.)
Unfortunately, producing Hydrogen is not very efficient, so at best, you typically end up with over power efficiencies that are very similar to today's hybrid vehicles.
Oh yeah; I'm definitely with you on that. I always bring that up when people talk about hydrogen cars. Hybrids too: "You realize that's really just a gasoline-powered car with a different kind of transmission, right?"
But the reason for my question isn't even necessarily related (directly) to vehicles, actually: The real point is, so long as we're using fossil fuels, I wonder what the theoretical limits on the efficiency of the getting-work-from-fossil-fuels process are for fuel cells, as different from that for heat engines.
Say you want to turn natural gas into CO2, water, and electricity. You can do what we currently do, which is burn it at a high temperature to power a steam- or gas- turbine -- OR, you can convert it to methanol and use that to power a fuel cell. And if you can avoid the Carnot heat-engine efficiency hit, I wonder what your theoretical max on efficiency is.
See the point of my question?
Still, I'm completely with you re. vehicles. That's right on.
Yep! With energy being so central to our lives, I wish people understood thermodynamics better.
What I don't understand is how to thermodynamically analyze fuel cells. I'd like to understand what their maximum theoretical efficiency is, and how it relates to the Carnot cycle.
[...Because the Carnot efficiency comes up in all sorts of interesting places. It's a fundamental limit even on solar cells; you just need to view them as heat engines working between a hot reservoir (the sun, via blackbody radiation), and a cold reservoir (the earth). I find that thought fascinating. You can even dream up (completely fantastical) mechanical heat engines using mirrors, that use photons as the "working fluid." Light goes in blue, comes out red! (directly related to temperature.)]
The most efficient internal combustion engine in the world is a diesel the size of a house that's in a container ship. It gets 50% efficiency.
For a heat engine, that's really quite good.
You're definitely right in that bigger is better: As you scale an internal combustion engine, the volume (and with it, energy per cycle) goes up as the cube of the scale, while surface area (and with it, heat radiated) only goes up with the square. So naturally, the huge diesels on container ships are among the most efficient real-life heat engines -- surpassed only by power plants.
But... turbines are also lucky to get 50%, actually! As I mentioned, the most efficient heat engines are the huge ones in power plants, and IIRC the best-ever-achieved is around 60%, using exotically-high temperatures and pressures (but I can't find a source for that.) This source cites 48% as a competitive efficiency for a coal-fired powerplant.
The point is that 50% is pretty impressive, actually.
Turbines do have big advantages: They're much more reliable than piston engines, because they're mechanically much simpler. But I'd like to dispel the myth that the reciprocating motion of piston engines is a major source of inefficiency. The K.E. of the pistons is negligible compared to the thermal energies involved. Rather, the reciprocating action is bad for reliability.
If it were my company I would be interested in finding out the real problem that the PHBs are trying to solve.
Perhaps it's just that, every time you become a manager of a department, you have to change something in order to show that you're working.
This comes from the idea that the manager who just smoothly keeps the same old thing happening over and over is the manager who doesn't get noticed, and therefore doesn't get promoted.
Ah, the working world! (Don't worry, academia is less different than you might hope. Career success is the art of self-promotion.)
That's one of the things that the guy selling the thing (in TFA) mentioned, actually.
My understanding:
This device creates vibrations in the target by rapidly heating and cooling it. Since these vibrations are in the tissue (especially bone) of your head, they reach your inner ear (cochlea) directly. So, they could help with certain kinds of deafness: namely, deafness caused by mechanical damage to the outer ear, but which leaves the nerves in the inner ear intact.
However, it seems you should be able to achieve exactly the same thing by sending acoustic waves through the skull by other means. In particular, all you need is a small speaker in direct contact with your head. That's exactly what certain existing hearing aids do. (See the Wikipedia article on Bone conduction for more.)
Hence, my opinion is that this microwave device really doesn't have any good uses which are not more easily and safely achieved by other means.
Sadovnik says that normal audio safety limits do not apply since the sound does not enter through the eardrums.
Such bullshit! (Directed at Sadovnik, not you, Digital).
Hearing loss usually has nothing to do with mechanical damage to the eardrum or ear; rather, it's almost always due to the fact that loud noises cause the cilia in your cochlea to get ripped out (and they do not grow back). This microwave thing is still exciting your cochlea, so it's doing the same damn thing. The only difference is that the vibrations originate within your head, whose tissue is rapidly being heated and cooled by the microwaves. But your cilia don't give a damn about where the vibrations come from.
Have you (or anyone) found a way to get XMOVE to work with MIT MAGIC COOKIE authentication? Or working with SSH X-forwarding? I can't seem to get that to work.
Did you even try the demo? On my dual-core Opteron with 4 gigs of RAM it was *painfully* slow
I wonder how much of that is client-side and how much server-side? As for the client-side issues: What browser were you using?
I tried the demo on a pretty standard desktop machine -- my guess is that it was about as beefy as yours (probably less, in fact) -- in a university computing lab (I can post back later with exact specs if you'd like) running some 2.x version of firefox, and I thought it ran reasonably fast.
That said, I do tend to agree with you. When we resort to running applications in a web browser, I feel like that speaks to a failure of some other part of the software infrastructure.
I wasn't aware that it was common practice to use real DSP-style reconstruction filters in computer graphics. I guess times are changing! I thought graphics cards typically rendered the scene at, e.g., 4x, and then used plain old bilinear interpolation to generate the new one. I remember when nVidia came out with its Quincunx supersampler; their marketing people were making a big deal out of it (and it was hardly an ideal reconstruction filter.)
Re:Environmental impact of travel
on
Terminal Chaos
·
· Score: 1
You missed the decimal point. Air travel, by that sites estimates, is actually.065kg per mile better.
Thank you! Good correction. Mod parent up.
Re:Environmental impact of travel
on
Terminal Chaos
·
· Score: 1
Oh yeah. I'm not disagreeing on anything. I just thought the numbers were interesting (and surprising).
Sorry -- maybe I'm missing something -- but what's the problem? You cast multiple rays per pixel, and that's all you need to do; you just average them to get the pixel color that you display on screen. It's basically the same way that current video cards handle antialiasing: Supersampling.
Re:Environmental impact of travel
on
Terminal Chaos
·
· Score: 1
So does auto travel, rail travel, ship travel, personal watercraft travel and any other powered machine you care to mention.
Sure. And while we're on the subject of other powered machines, it's actually dinky little engines like those in lawnmowers and weedwackers that pump out a lot of unburnt hydrocarbons, not cars.
But as for planes vs. cars: this site gives "29 kg CO2. per person mile traveled" for aircraft, but "gasoline has 8.87 kg (19.56lbs) of CO2 per gallon" and "The US avg. is about 25 mpg." so, assuming one person in a car (worst case scenario), then we have (8.87kg/gal)/(25 miles/gal) = 0.3548 kg/mile of CO2. Hence, air travel produces 81.7 times the CO2 per person-mile as auto travel -- and that's assuming no carpooling, which increases the number even further.
Re:Screwed up priorities?
on
Terminal Chaos
·
· Score: 1
Who the hell are you to tell me or anyone else what our priorities should be?
A: A guy on the internet.;-)
Anyway, I tend to agree with you, but I have to admit that air travel is not without externalities. Mainly, the demand for flights pumps a lot of CO2 into the atmosphere, and that hurts everybody. I guess that's not stopping me from taking the plane when I want to get places, though.
That doesn't stop you spouting off on message boards though, does it? [...] Leave C++ opinions to people who understand it and use it every day.
Don't be a jerk. I was not saying "C++ sucks." I was saying that it has some features that I find confusing.
Other Slashdot users are no doubt in the same boat, but they couch their arguments in more authoritative language. They may even be experts. Regardless, it sounds an awful lot like they're saying the same thing. For just one example, here's a quote from a post that was modded "+4, Interesting:"
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
This speaks about, in more general terms, the same issues I was addressing in my post. My post differs in that (1) it was more specific about the language features that lead programmers to hide memory leaks inside abstractions, and (2) I admitted that I am not an expert. Both aspects make my post easier to attack, but they are really just matters of presentation.
As for point #2 above: I want to stress that jumping on people for admitting ignorance on Slashdot will reduce the honesty that you'll see on these boards. It creates more incentive for people to speak in authoritative language without in fact being experts -- and that, unlike the posts of admitted non-experts, really is a problem.
At any rate: Though not an expert in C+++, I am a reasonably competent programmer and a decent when it comes to algorithms, so I don't think my comments were entirely pointless. I think it's worth mentioning which features of C++ cause confusion and act as barriers to entry.
I was also looking for a few practical suggestions, since I made it very clear that I still have things to learn. Obviously I'm not investing a great deal of time into training myself in C++, but if somebody had a few tips that they could give and I could receive without much effort (on either's part), then I was clearly welcoming them. Hence, I appreciate these parts of your post:
Um, there*is* only one way for each (well, ok, you can overload the constructor but I fail to see how that's confusing).
(Translation: Take a second look at the operators, and maybe they'll make sense.)
and
Plus, if you learn what a smart pointer is then you can mostly forget about writing copiers and destructors - let the compiler do it for you.
It's true, there are a lot of C++ features I don't really understand.
Not "getting" RAI, though, is not, I think, where my problem lies. It makes perfect sense to write code that way. The problem for me is implementing RAI in C++: It's all the damned constructors and destructors that get me. I want one way to make a new FOOMINATOR, one way to kill a FOOMINATOR, and maybe one way to copy a FOOMINATOR. Unfortunately in C++ this isn't enough! My issue is that I get confused with all the "ways in" and "ways out" of existence that objects have. At the very least, I wish C++ would do away with its "automatically do a shallow copy when you haven't provided an appropriate constructor for this case" policy and produce an error (or at least a warning), so I'd know when I was doing something stupid. I expect that if I wrote C++ more I'd get used to it, but as it stands I'm pretty happy achieving pretty much the same thing with C with structs, functions, and multiple files. Then, I do pretty much the same things as all the C constructors and destructors, but it's very explicit, so I understand what's happening. The difference between this C approach and C++ strikes me as syntactical sugar which, for my uses, is currently more confusing than useful.
But hey, I don't program for a living. I program for fun, and for my research (though MATLAB, horrid language that it is, is largely taking over in my toolbox for that, since its matrix manipulation and its libraries are wonderful. The commandline interface is also very nice; it makes for a very good debugging environment). So it's doubtful that I'll pick up C++ any time soon -- unless someone has a nice set of libraries they can recommend to duplicate MATLAB's functionality in C++.
So you see why, for this user, C++ hasn't caught on. Right now, I don't see anything at the top of the learning curve that makes the slope worth climbing. I'd rather spend my time (when I'm not procrastinating on Slashdot) learning theory.
I hadn't heard of Frank Tipler until you mentioned him. WOW! That man speaks crazy talk.
And he has a faculty position.
I'm starting to realize that academia is similar in some ways to pop-culture, in that name recognition is everything. It differs just in that the publicity stunts you do need to impress a different sort of person.
In a way, it's career advice. *Goes back to getting PhD*
Pick a woman at random. Let P be the probability that she has STD X. Then have sex with her. Repeat, for a total of N women.
The probability that you have had sex with at least one woman infected with STD X is given by,
1 - (1 - P)^N
Now consider some numbers. Let STD X be Herpes Simplex, Type 2, which 25% of women have. (This is just one variety of herpes; it's usually genital). Next: You say that, as of several years ago, you had had sex with between 35 and 45 women. By now, it's safe to assume N >= 45. As a conservative estimate, choose N=45. Now plug in the numbers:
Now, I've left some things out, I know: 99.9998% is just the probability that you've had sex with at least one woman with HSV2; it's not the probability that you actually have HSV2, because the probability that you will catch HSV2 if you have sex with an infected person is less than 100%.
You can run some more accurate numbers yourself if you care. The point is that the real facts of life aren't actually all that pleasant, and "sexual positivism" takes a degree of willful ignorance of them.
Slashdot Mirror
The Tesla uses is a brushless AC motor
Is this a synchronous machine or an induction motor? (I ask because "brushless" usually refers to synchronous machines). I had thought that the Tesla used an induction motor (hence the name)... Does it actually use a synchronous motor?
permanent magnet, etc. They don't always peak at intuitive spots.
Yep. Though the permanent-magnet one pretty much does behave like the simple DC motor from physics 101. Also the shunt wound, if you have the luxury of separate field and armature current supplies.
there is very little reason to use a DC motor outside of household applications.
Well... except permanent-magnet brushless DC motors (almost identical to AC synchronous motors) -- which are pretty much the best motors you can have. And their performance is basically that of the theoretical DC motor!
This isn't the issue. It's true that high rotation speeds are a problem in mechanical systems, but a car axle doesn't reach those speeds. Suppose a wheel has a radius of 1.25 ft (an underestimate), and that the car is traveling at a top speed of 200 mph. This gives a rotational speed of 2240 RPM. For comparison, an automotive engine might have a redline (max crankshaft speed) around 6000 RPM. The point is that 2000 RPM is not a particularly scary angular velocity.
Gearboxes are really for converting torque to rotation.[...]Mind you as well that electric motors have bags ans bags more of torque than IC engines...
All true. Electric motors are way more ideal for turning wheels than IC engines. Still, you do need a gearbox (even if it's just the 2-speed one this car has).
Consider two extreme approaches to electric motor sizing for a car:
1 - Choose a motor torquey enough that you don't need gears. Such a motor will either (1) draw an insane current, or (2) have very many windings. Of the two, #2 is more efficient, as torque increases linearly with either the number of windings or the current, whereas resistive power loss increases only linearly with # of windings and quadratically with current.
2 - Choose a motor that can run at a high enough top-end speed without gears. Such a motor will either (1) require an insane voltage, or (2) have very few windings. Of the two, #2 is preferable, as #1 will cause the insulation on the coils to break down. Additionally, #1 keeps weight down.
You see that the requirements of situation 1 and situation 2 are mutually exclusive. Hence, we choose a compromise. Unfortunately, when we do this what we end up with is a motor which either can't handle the low end, can't handle the high end, or both -- so we need gearing to deal with that, and keep the motor running in its most efficient range.
Luckily, this efficient range is much wider than that for an IC engine, so the gearbox can be smaller, lighter*, and more efficient than that for a gasoline-engine car.
(* but don't think electric cars are lighter: they're not. The weight of the motor (which is basically a big chunk of intricately-arranged copper) usually more than offsets these other savings; electric cars are heavier. That said, the electric motor's greater torque offsets the increased mass, so if you're just considering acceleration, the electric car handily wins.)
By any chance, was the competition you refer to Formula Hybrid? (If so, I worked on that too!)
Unfortunately, producing Hydrogen is not very efficient, so at best, you typically end up with over power efficiencies that are very similar to today's hybrid vehicles.
Oh yeah; I'm definitely with you on that. I always bring that up when people talk about hydrogen cars. Hybrids too: "You realize that's really just a gasoline-powered car with a different kind of transmission, right?"
But the reason for my question isn't even necessarily related (directly) to vehicles, actually: The real point is, so long as we're using fossil fuels, I wonder what the theoretical limits on the efficiency of the getting-work-from-fossil-fuels process are for fuel cells, as different from that for heat engines.
Say you want to turn natural gas into CO2, water, and electricity. You can do what we currently do, which is burn it at a high temperature to power a steam- or gas- turbine -- OR, you can convert it to methanol and use that to power a fuel cell. And if you can avoid the Carnot heat-engine efficiency hit, I wonder what your theoretical max on efficiency is.
See the point of my question?
Still, I'm completely with you re. vehicles. That's right on.
That is the theoretical limit.
Yep! With energy being so central to our lives, I wish people understood thermodynamics better.
What I don't understand is how to thermodynamically analyze fuel cells. I'd like to understand what their maximum theoretical efficiency is, and how it relates to the Carnot cycle.
[...Because the Carnot efficiency comes up in all sorts of interesting places. It's a fundamental limit even on solar cells; you just need to view them as heat engines working between a hot reservoir (the sun, via blackbody radiation), and a cold reservoir (the earth). I find that thought fascinating. You can even dream up (completely fantastical) mechanical heat engines using mirrors, that use photons as the "working fluid." Light goes in blue, comes out red! (directly related to temperature.)]
Is there a theoretical physicist in the house?
The most efficient internal combustion engine in the world is a diesel the size of a house that's in a container ship. It gets 50% efficiency.
For a heat engine, that's really quite good.
You're definitely right in that bigger is better: As you scale an internal combustion engine, the volume (and with it, energy per cycle) goes up as the cube of the scale, while surface area (and with it, heat radiated) only goes up with the square. So naturally, the huge diesels on container ships are among the most efficient real-life heat engines -- surpassed only by power plants.
But... turbines are also lucky to get 50%, actually! As I mentioned, the most efficient heat engines are the huge ones in power plants, and IIRC the best-ever-achieved is around 60%, using exotically-high temperatures and pressures (but I can't find a source for that.) This source cites 48% as a competitive efficiency for a coal-fired powerplant.
The point is that 50% is pretty impressive, actually.
Turbines do have big advantages: They're much more reliable than piston engines, because they're mechanically much simpler. But I'd like to dispel the myth that the reciprocating motion of piston engines is a major source of inefficiency. The K.E. of the pistons is negligible compared to the thermal energies involved. Rather, the reciprocating action is bad for reliability.
If it were my company I would be interested in finding out the real problem that the PHBs are trying to solve.
Perhaps it's just that, every time you become a manager of a department, you have to change something in order to show that you're working.
This comes from the idea that the manager who just smoothly keeps the same old thing happening over and over is the manager who doesn't get noticed, and therefore doesn't get promoted.
Ah, the working world! (Don't worry, academia is less different than you might hope. Career success is the art of self-promotion.)
That's one of the things that the guy selling the thing (in TFA) mentioned, actually.
My understanding:
This device creates vibrations in the target by rapidly heating and cooling it. Since these vibrations are in the tissue (especially bone) of your head, they reach your inner ear (cochlea) directly. So, they could help with certain kinds of deafness: namely, deafness caused by mechanical damage to the outer ear, but which leaves the nerves in the inner ear intact.
However, it seems you should be able to achieve exactly the same thing by sending acoustic waves through the skull by other means. In particular, all you need is a small speaker in direct contact with your head. That's exactly what certain existing hearing aids do. (See the Wikipedia article on Bone conduction for more.)
Hence, my opinion is that this microwave device really doesn't have any good uses which are not more easily and safely achieved by other means.
Sadovnik says that normal audio safety limits do not apply since the sound does not enter through the eardrums.
Such bullshit!
(Directed at Sadovnik, not you, Digital).
Hearing loss usually has nothing to do with mechanical damage to the eardrum or ear; rather, it's almost always due to the fact that loud noises cause the cilia in your cochlea to get ripped out (and they do not grow back). This microwave thing is still exciting your cochlea, so it's doing the same damn thing. The only difference is that the vibrations originate within your head, whose tissue is rapidly being heated and cooled by the microwaves. But your cilia don't give a damn about where the vibrations come from.
Ugh.
Have you (or anyone) found a way to get XMOVE to work with MIT MAGIC COOKIE authentication? Or working with SSH X-forwarding? I can't seem to get that to work.
So, in other words, I can download this app and run it locally? For free (and Free)? Wow! That really sounds just ... like ... openoffice?
The funny thing is, OpenOffice takes about the same amount of time to load.
(At first, the above sentence was intended as a joke; then I realized, sadly, that it was actually true -- at least before the site got Slashdotted.)
Did you even try the demo? On my dual-core Opteron with 4 gigs of RAM it was *painfully* slow
I wonder how much of that is client-side and how much server-side? As for the client-side issues: What browser were you using?
I tried the demo on a pretty standard desktop machine -- my guess is that it was about as beefy as yours (probably less, in fact) -- in a university computing lab (I can post back later with exact specs if you'd like) running some 2.x version of firefox, and I thought it ran reasonably fast.
That said, I do tend to agree with you. When we resort to running applications in a web browser, I feel like that speaks to a failure of some other part of the software infrastructure.
I wasn't aware that it was common practice to use real DSP-style reconstruction filters in computer graphics. I guess times are changing! I thought graphics cards typically rendered the scene at, e.g., 4x, and then used plain old bilinear interpolation to generate the new one. I remember when nVidia came out with its Quincunx supersampler; their marketing people were making a big deal out of it (and it was hardly an ideal reconstruction filter.)
Thank you! Good correction. Mod parent up.
Oh yeah. I'm not disagreeing on anything. I just thought the numbers were interesting (and surprising).
Sorry -- maybe I'm missing something -- but what's the problem? You cast multiple rays per pixel, and that's all you need to do; you just average them to get the pixel color that you display on screen. It's basically the same way that current video cards handle antialiasing: Supersampling.
Sure. And while we're on the subject of other powered machines, it's actually dinky little engines like those in lawnmowers and weedwackers that pump out a lot of unburnt hydrocarbons, not cars.
But as for planes vs. cars: this site gives "29 kg CO2. per person mile traveled" for aircraft, but "gasoline has 8.87 kg (19.56lbs) of CO2 per gallon" and "The US avg. is about 25 mpg." so, assuming one person in a car (worst case scenario), then we have (8.87kg/gal)/(25 miles/gal) = 0.3548 kg/mile of CO2. Hence, air travel produces 81.7 times the CO2 per person-mile as auto travel -- and that's assuming no carpooling, which increases the number even further.
A: A guy on the internet. ;-)
Anyway, I tend to agree with you, but I have to admit that air travel is not without externalities. Mainly, the demand for flights pumps a lot of CO2 into the atmosphere, and that hurts everybody. I guess that's not stopping me from taking the plane when I want to get places, though.
Don't be a jerk. I was not saying "C++ sucks." I was saying that it has some features that I find confusing.
Other Slashdot users are no doubt in the same boat, but they couch their arguments in more authoritative language. They may even be experts. Regardless, it sounds an awful lot like they're saying the same thing. For just one example, here's a quote from a post that was modded "+4, Interesting:"
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.This speaks about, in more general terms, the same issues I was addressing in my post. My post differs in that (1) it was more specific about the language features that lead programmers to hide memory leaks inside abstractions, and (2) I admitted that I am not an expert. Both aspects make my post easier to attack, but they are really just matters of presentation.
As for point #2 above: I want to stress that jumping on people for admitting ignorance on Slashdot will reduce the honesty that you'll see on these boards. It creates more incentive for people to speak in authoritative language without in fact being experts -- and that, unlike the posts of admitted non-experts, really is a problem.
At any rate: Though not an expert in C+++, I am a reasonably competent programmer and a decent when it comes to algorithms, so I don't think my comments were entirely pointless. I think it's worth mentioning which features of C++ cause confusion and act as barriers to entry.
I was also looking for a few practical suggestions, since I made it very clear that I still have things to learn. Obviously I'm not investing a great deal of time into training myself in C++, but if somebody had a few tips that they could give and I could receive without much effort (on either's part), then I was clearly welcoming them. Hence, I appreciate these parts of your post:
Um, there*is* only one way for each (well, ok, you can overload the constructor but I fail to see how that's confusing).(Translation: Take a second look at the operators, and maybe they'll make sense.)
and
Plus, if you learn what a smart pointer is then you can mostly forget about writing copiers and destructors - let the compiler do it for you.These both sound like good suggestions.
So: Don't be obnoxious, but thanks for the tips.
...because Marketing and Sales would have a harder time selling Plus Plus C. Sounds like a Japanese cola.Me, I was thinking we'd call it "Doubleplus C," and then it'd just sound too Orwellian.
It's true, there are a lot of C++ features I don't really understand.
Not "getting" RAI, though, is not, I think, where my problem lies. It makes perfect sense to write code that way. The problem for me is implementing RAI in C++: It's all the damned constructors and destructors that get me. I want one way to make a new FOOMINATOR, one way to kill a FOOMINATOR, and maybe one way to copy a FOOMINATOR. Unfortunately in C++ this isn't enough! My issue is that I get confused with all the "ways in" and "ways out" of existence that objects have. At the very least, I wish C++ would do away with its "automatically do a shallow copy when you haven't provided an appropriate constructor for this case" policy and produce an error (or at least a warning), so I'd know when I was doing something stupid. I expect that if I wrote C++ more I'd get used to it, but as it stands I'm pretty happy achieving pretty much the same thing with C with structs, functions, and multiple files. Then, I do pretty much the same things as all the C constructors and destructors, but it's very explicit, so I understand what's happening. The difference between this C approach and C++ strikes me as syntactical sugar which, for my uses, is currently more confusing than useful.
But hey, I don't program for a living. I program for fun, and for my research (though MATLAB, horrid language that it is, is largely taking over in my toolbox for that, since its matrix manipulation and its libraries are wonderful. The commandline interface is also very nice; it makes for a very good debugging environment). So it's doubtful that I'll pick up C++ any time soon -- unless someone has a nice set of libraries they can recommend to duplicate MATLAB's functionality in C++.
So you see why, for this user, C++ hasn't caught on. Right now, I don't see anything at the top of the learning curve that makes the slope worth climbing. I'd rather spend my time (when I'm not procrastinating on Slashdot) learning theory.
I hadn't heard of Frank Tipler until you mentioned him. WOW! That man speaks crazy talk.
And he has a faculty position.
I'm starting to realize that academia is similar in some ways to pop-culture, in that name recognition is everything. It differs just in that the publicity stunts you do need to impress a different sort of person.
In a way, it's career advice. *Goes back to getting PhD*
Pick a woman at random. Let P be the probability that she has STD X. Then have sex with her. Repeat, for a total of N women.
The probability that you have had sex with at least one woman infected with STD X is given by,
1 - (1 - P)^N
Now consider some numbers. Let STD X be Herpes Simplex, Type 2, which 25% of women have. (This is just one variety of herpes; it's usually genital). Next: You say that, as of several years ago, you had had sex with between 35 and 45 women. By now, it's safe to assume N >= 45. As a conservative estimate, choose N=45. Now plug in the numbers:
1 - (1 - .25)^45 = 0.999998
Need Acyclovir?
Now, I've left some things out, I know: 99.9998% is just the probability that you've had sex with at least one woman with HSV2; it's not the probability that you actually have HSV2, because the probability that you will catch HSV2 if you have sex with an infected person is less than 100%.
You can run some more accurate numbers yourself if you care. The point is that the real facts of life aren't actually all that pleasant, and "sexual positivism" takes a degree of willful ignorance of them.