Speaking ONLY for myself; I read the FA, and I still see no significant reason to move away from standard c.
Know what would make me move? A syntax identical to the Python 2-series that compiled down to machine efficiencies similar to c. Now that's a beautiful syntax, a real step in the right direction. If I was writing it, I might be a little more strict about the indentation, so as to prevent things like lambda expressions, space/tab confusion, and single-line run-on, but overall, it's really, really nice as is. Add a good compiler and build in some portability, and I'd bite.
But... until then, I honestly don't think there is anything really worthwhile I could do in c++ that I can't do in c, generally at lower memory cost, higher speed, fewer "black boxes", and better portability. Which is not the same thing as saying there isn't anything unique to c++... just that the "good stuff" doesn't really add value I don't already have access to, albeit using much finer-grained techniques.
Objective c is pretty much the same... I find that the whole idea of objc is highly overrated, most of the added features are time- and memory-adding crutches... just a thin layer added to c that pressures you to use a messaging model you could have easily implemented yourself if you needed it, which you likely wouldn't -- if OSX wasn't chock full of it.:^)
On the Mac, I write an objc wrapper that talks to the OS, then write the core code in c. The only projects that I really write c++ for are those that arrive on my desk already written in c++, and which need my attention for porting, upgrades, etc. and even then... c++ methods end up wrapping c, generally speaking.
From my perspective, c++ and objc are both solutions seeking non-existent problems; solutions with fairly heavy penalties and which create overcomplicated implementation paradigms that take the focus away from the problem at hand. Too much emphasis on making programming "easy" and not enough on making it good. When I have to put the details together, I have to care about them. When I depend on the compiler to write part of the code for me, I'm going to get mediocre performance from a one-size-fits-all model without any real option to do anything about it. And I'm not just talking about code generation, although that's a problem too: I'm talking about managing the stack, making sure megabytes of cruft aren't glued to the application because some built-in capability incurs dependencies upon a whole series of frameworks or libraries, not having to fight the compiler-writers academic preconceptions about globals... I just prefer a finer degree of control, it suits me well.
And... yeah, I'd write in assembly if I could, there's another whole layer of speed, size and related benefits to be had there, but the portability issues, even within the same OS, are just too troublesome unless the code is for a controller where I know the hardware isn't going to change. Now *those* are fun projects.
Well, lets put it this way, then: Windows 8 will be a slow piece of shit. In addition, it looks like it will be incompatible with every piece of windows software currently out there, unless I completely misunderstand (they're telling us developers we can't use the old tools... so I take that to mean that the old tools won't produce usable code, therefore previously released code.... junked.)
The one thing of value Windows offered -- to me -- was long term backwards compatibility. With that gone, it's basically an entirely new OS, and you know what.. no thanks. I'd rather move to linux, which is very well established by comparison. Assuming my Mac somehow became dysfunctional.
No matter what rep you work for, their office - through the auspices of a series of elected officials - is known to have completely and utterly broken their solemn oaths; known to have violated the constitution repeatedly and deeply; and you... you suggest we trust the current rep in that office, that we spend our time providing suggestions to them.
You're hilarious, you are.
But I'll tell you what. When the reps you work for rewrite the laws to respect the commerce clause for what it actually was meant to accomplish; when they reverse the ex post facto laws they've put into the legal system; when they stop trampling the bill of rights; maybe it'll be worth contacting them without bribe in hand.
Not that anyone sensible is holding their breath for any of that, mind you.
No, actually, as atmospheric CO2 increases, plants will grow more and more enthusiastically, increasing crop yield and quality, which in turn will directly influence human health issues in a positive direction.
Well, when there's a 3000 foot ice cliff looming over the upper US states again (instead of a 3001 foot ice cliff), and fleeing Canadians are the latest immigrant scourge, the warmers can just tell us that they told us so, it was global warming after all, and nyah-nyah, and etc. While the farmers in the south continue to enjoy higher crop yields. CO2 being a huge booster of plant metabolism and all.
Your libraries may let you find memory management problems quicker, but they don't save you having to think about the memory management, wasting brainspace that would be better used on the problem the application's trying to solve. (Either that or they abstract it away enough that you no longer have hand control - at which point, you've just come a long way around to where those of us in better languages already are)
No, you don't understand at all. My libs let me write to a model that doesn't carry the release-level baggage that your "better languages" do; consequently my release code is both faster and lighter than that produced with, for instance, objc or c++, etc. But during development, I receive all manner of feedback if anything goes wrong, which bulletproofs the things I'm doing BEFORE they are let loose without protection, lightweight and fast. Your "better language" is always dragging around heavy and clumsy memory managers that are generalized and not optimal; my memory code is much better because it's always case-specific. And it doesn't waste the user's resources. And there's never any GC stumbling about, either.
When we come to libraries, you seem to be taking the position that your code will always be better than other people's.
No. I'm taking the position that my code is more maintainable by me than other people's, and the only reasons I say that are because (a) I have the source and (b) I wrote the source, so I understand it intimately. For any framework where I don't have the source, fixing a problem *is* a problem. Trying to get Apple to fix a framework bug is like trying to push a Sherman tank uphill with a wet noodle. If I do have the source, for instance, lets say the JPEG libs, there can be massive slogging around trying to figure out why, for instance, setting the chroma resolution to 1x1 instead of 2x2 doesn't work in the new lib, but did in the old lib. Whereas if I use my jpeg library, not only do I have control over this (and it continues to work), but I can also load all those jpeg variants that won't load with the standard IJPG libs and I can let a configurable number of cores loose on different compression blocks, which gives me a huge speed advantage over, say, the IJPG libs. Likewise, if I use my treeview, the treeview works properly. If I use theirs... well, just Google it, you'll see the problems, which are many. Their treeview is a nightmare collection of screwups. And so on.
The current American mentality is witchhunt first, then never, ever forgive. Felon? Employment-wise, you're hammered. Forever. Sexual *anything* to do with the law? Employment-wise, you're hammered. Forever. Anything that the social retards think isn't Good for the Children? I'm talking drinking, drugging, tattoos, piercings, partying, "planking", nudity of any kind, shooting, marching for any particular cause, flash mobbing, pranking, sexting, imitating the cognitively-impaired people on Jackass, extreme sports... or even being THERE when someone ELSE is doing any of these things... employment-wise, you're hammered.
And if, for some reason, things aren't quite that bad yet, don't worry, they'll very likely pass ex post facto laws to make it so later; just as they already have with guns and the various lists -- do not fly, do not sell to, violent/sexual offender, terrorism. And they'll conflate ridiculous things too - 17-year-old == child == peeing in bush, etc. You can do the most innocuous thing that you think is perfectly ok -- like photograph your cute little infant in the tub -- and end up with your mug shot right next to Victor the Vaginal Butcher, unemployable and forced to move into a box under that bridge downtown you've been throwing your coffee cups over the past few years.
So... you don't appreciate StupidBook becoming a threat to your job and you life and your family? Get out before it happens. Delete everything on your page before you go, and un-friend everyone. It's all you can do. It won't be enough - this is truly becoming a permanent record society that never, ever forgives, criminalizes the ridiculous, and no longer even gives lip service to the ideas of forgiveness or rehabilitation - but it's a start in the right direction.
Also - speaking as a photographer of many years - stop photographing people. Just stop. Nature, old, non-governmental architecture, that's the thing to shoot. Photography is turning into the next minefield. Same thing goes for video, if you're into video. Not just because it might harm you; but because it also might harm them. You might photograph someone in a place they really would prefer others not know they were, for whatever reason... you might catch that funny drunk guy, share the pic, and cause him to lose his job and livelihood and really, really hurt his entire family... or you might shoot that lovely government building you paid for and find yourself answering very hard questions from very hard people about why there is a bottle of bleach under your sink and ammo for your 22 cal. match rifle in your closet, said people showing up right at your job, complete with warrant from their pet oath-breaking judge. Followed immediately by your very own pink slip, because employers are hugely threatened by such events. And now you're unemployable. Welcome to America 2011.
in an ideal society where you could be whatever you want, odds are that no one would want to be a prostitute or a porn star.
Why act? Get paid to stand on a stage or in front of a camera, pretend you're someone you aren't, and act out fictional relationships, situations, times... so people can lose themselves in the fantasy... is that part of your "no one would do THAT" idea? I'm guessing not.
What about a masseuse? Get paid to rub someone's body, all over, to make them feel better. That ok in your ideal society? I'm still guessing, yes. Or a physical therapist: rubbing to repair, among other things. Exercise, range of motion, that all sure feels good (I'm a martial artist... very familiar with the pleasures of working the body from either end.) Again, are those things any part of your "gee, no one would do THAT" idea? I'm still guessing not.
So we've established that some people are ok with faking who they are for fun, pleasure and recompense; others are ok with extended, long term body contact by appointment, with oils, atmosphere and more, to make you feel better, again for recompense. And this is all perfectly ok. Right? Your imaginary ideal society would allow acting and massage and physical therapy, yes?
Well, a sex worker does both of these. There may be even less body contact than with a masseuse; there may be less detailed acting than you'd see on stage or film (or not, if you've chosen well.) So what's the problem? I'll tell you: the problem is social conditioning; the problem is in you. Accept the performance as it is delivered, as an exchange, and you'll be fine. Try to convince yourself you know what's going on in the other person's head, and it's all bad, and you know better than the performer. that your payment has bought something you weren't offered... and you're simply proving you're a pompous ass. Otherwise, enjoy the performance, treat the performer with respect, appreciate the time and energy and skill, pay what is due, and move along.
It is simply pitiful watching you and your post's parent trying to paint a fixed morality picture -- in your case, an entire society -- for people who don't agree with you. Remember: everyone is different. That means you don't know what's going on in their heads, and you don't know what is ideal. Period. There are people who turn to prostitution (and McDonalds) out of desperation; there are others who are there because it suits them just fine. Anyone who is doing anything out of desperation should work to get clear; anyone who is doing what they want in a consensual and informed manner -- regardless of what it is -- has absolutely no need of your clueless moralizing.
Sex definitely isn't the one-dimensional thing you've been conditioned to think it is. Getting beyond that illusion will instigate beneficial personal growth. Count on it.
Also, good looks, athleticism, intuition, a desirable figure, a kind heart... these are perfectly fungable assets. You have no right to declare any of them off limits, in any combination.
if these prostitutes had all the merits you've mentioned, but also a family to help them through setting up a normal life, they would not be prostitutes.
That is simply utter nonsense coming from someone who is baffled about sexuality. Sex can be a service; a payment; a gift; a kindness; an act of love; combinations thereof and more. And furthermore, it is normal for it to be all of those things. Your limited view of sexuality has completely blinded you to the many dimensions that exist outside of your concept of people only engaging in the act for reasons you approve of. Luckily, what you approve of is wholly irrelevant.
Python 2.x comprises an awesome language series. A real shame about python 3's incompatabilities, but we still have python 2.x, so it's far from a total loss. And perhaps ol' Guido will wise up and turn back to maintaining a properly compatible upward development course with the 2.x series. One can hope.
Huge fan of Python, myself. This is my python code for instance... it's an aurora detection and prediction system that sends me an SMS whenever I need to get out there with my camera. And as you can see, it works for me. Uses PyEphem and PIL, otherwise comprised of my code, my meter and web scraping libraries, etc.
No. It's not harder. It's just different. Java poses some huge challenges at times; to be "good", you should be able to say you can meet them. c challenges are very different, and frankly, they're simpler, but again, to be good, you still have to meet them. There are some traps -- the "standard" (K&R and derived) code formatting puts an instant hurt on comprehension, and a lot of programmers have fallen for that because no one has taken the time to show them there is a better way -- many of them are now habituated and can't get beyond it.
The only languages I've ever run into that were legitimately "harder" brought a different type of challenge to the table: APL, for instance, is actually a harder language because you have a lot of non-intuitive learning to do, and you need to make it intuitive if you're going to be any good. It's like learning Klingon.
Some languages form a natural progression of learning: asm to forth to c is a very natural progression, for instance, even though one is direct, one can be interpreted, compiled or byte-coded and is RPN-ish to boot, and the last is almost always primarily algebraic and compiled. So it's an easy learning curve. There's nothing easy about APL, it'll make your brain bleed. Lisp is no picnic, either; visually speaking, it's a bitch, and that makes it difficult to learn. Python is so easy to learn -- and powerful -- it's almost ridiculous. Perl is powerful, but hugely annoying in its non-intuitive symbol-soupness and the first time you try to deal with Other People's Code in perl, you'll learn why the best programmers moved right over to Python as soon as they understood what it offered.
Anyway, no, Java and c... not really different in terms of getting good. Perhaps what has really caught your attention is that there aren't that many good programmers, period. That's where languages with training wheels - memory, lists, dictionaries, the lovely exception handling exemplified in python -- help them along far enough so they can make production code anyway. The resulting apps are inevitably slower, larger, and more fragile than what a good programmer would have made, but you know, they mostly do the job, and that's what the poor public has become accustomed to.
I start the "Island HD" game on my ipad, it cranks for a minute, then crashes. Yep, pretty much par for the course. I start it again, this time it runs. Looks like the OS had a little more memory in a single chunk that time... I start the NPR news app, it can't get to the server, it crashes in the middle of loading a news item. Same thing for my Pulse news reader. Can't get to an article... crash. Chess with Friends: start it, it's a toss up if it'll crash or not. Once running, it appears stable, though. On the Mac, every time a cron job starts, OSX pukes an (incorrect) error message to the console. I use cron a lot, so that got really old... and so I fixed it. And then we get into issues where some fool thinks its ok to constantly prod you to "connect to facebook" and leaves you no way to say, "I'm not on idiot facebook, nor will I ever be, so stop doing that." Just lousy programmers everywhere.
See, what you've just admitted is simply that you failed to even try to solve the problem. Like most things in programming, it's amenable to effort, and there are significant rewards.
First thing I do on a new project is incorporate my development memory code; I get pools, cached pre-allocators, null pointer checking prior to every use, prior to deallocation, and on allocation; memory consumption tracking both in amount and allocate/deallocate counters, reference counting, over- and under-run barriers, named, unfreed capture and unfreed re-allocation trapping, barriered arrays and exposed (defeatable) array accessors, and a good deal more. This adds about 50k to the target executable during development.
Then, when it's release time, I simply switch to the release version, which recompiles into lean, mean memory handling, about 3k, knowing that any problems -- which, frankly, after decades of doing this, are few -- have already been caught. Exposed accessors and so forth are still there, no overruns happening, etc. So I don't spend time "doing memory management"; No null pointers, no buffer overruns, no issues at all, and no particular work to make it all happen. Code once, enjoy the many, many benefits thereafter. Completely under control. And that goes for a lot of other things you might consider "c issues", too -- over the years, you (well, I) learn to solve problems in a way that moves forward with you. These are *tiny* chunks of code, not these massive frameworks from Waste-O-Rama, Inc.
In the end, I produce a faster, leaner, more efficient app that saves the user time with every action; is much easier to maintain (either fix or upgrade) because it doesn't depend on external libraries and frameworks I don't have control over; saves download time simply because it's much smaller than a comparable C++ etc. application; doesn't unethically trade the user's application space for any perceived development effort savings, and is known to have a very high degree of correctness on its way out the door. If someone finds a problem, I can fix it in minutes, because there are no black boxes. Users like that, too... email in, fix comes back in half an hour. Kind of sets them on their heels, for some reason... guess they're used to something else, eh?
I even get to use all manner of OO techniques - objects with built in functions, allocators, class functions, object functions, etc., but the difference is, I have complete control over them; I'm not at the mercy of the compiler, framework, or otherwise private libraries, because they're built using my own code and methods. I'm not tied to any particular GUI generator (that's a real issue in Apple's OSX), and I don't have to worry about dragging little lines around to connect my objects -- that's all done "in your face", in code -- no hidden black box nonsense. My buddy back on the east coast spent many hours last week trying to incorporate Apple's treeview control... I have a pile of email from him complaining about the built-in bugs... I just LOL'd and showed him my treeview library. Bugfree and more functional than Apple's, anyway. Nothing beats having your own code. Other People's Code is almost always an invitation to trouble, and that is especially true if it is some major company's, because they simply are not going to be responsive to your needs.
And as to race conditions... I write real time, multi-threaded signal processing code. I invented some of the current AFSK modes. My latest project is a multicore aware, user-core-utilization selectable image processing suite -- in beta now (see it on the middle two monitors?) -- that makes Aperture look like a box of slow, clumsy crayons, but is a fraction of its size and offers *far* more in terms of functionality, even incorporates an astrophoto processing system. About 99% c, the rest is an obj-c application wrapper. I think I might know a little bit about how not to trample my own toes in this regard.
That would very much depend on the compiler. I just looked at the code output of the GCC compiler when fed objective C (very close to c), and trust me, the code was HORRIBLE. GCC is a pretty modern compiler, as things go, and there's one case where code generator optimization -- and I use the term extremely freely here -- was apparently not even attempted, or if attempted, is a mad fail.
I'm sure, speaking as a very experienced asm programmer, that some compiler, somewhere, someday, could outcode me on some given architecture (and more likely on architectures that are slovenly, like Intel's usual weirdness), but I think it's worth reporting that I've not yet encountered said compiler.
The most powerful tool -- and the one with the most precision -- is asm. And it certainly isn't for everyone. What YOU probably meant to say is "C++ and other tools of increasing abstraction aren't for everyone."
Actually, I think we're dealing with two completely different definitions of "close to the iron here". Nothing wrong with yours (low level architectural feature access), but yours isn't the usual meaning, either. The usual meaning is that a line of c produces easily predictable results for a particular architecture, and therefore someone who knows the CPU architecture, compiler habits, and c itself can do a good job of keeping the code efficient within the bounds of what the compiler does. This becomes more and more difficult as the compiler sophistication upscales, eg with C++, and that's why c, rather than c++, gets the accolade.
Also, an argument could be made for some versions of C having low level architectural feature access by virtue of simply being able to say #asm at any time and properly utilizing the compiler's version of the #asm/#endasm interface. Although as far as I'm concerned, if you're going to do that, you probably should have been writing in asm anyway...
ASM is far higher than "molecular level", in fact, it's not all that far off from C (which is one of the benefits of C.) The real disadvantage of ASM isn't what the uninformed think it is -- the bogus claim that it doesn't get much done per line -- the main disadvantages are that each CPU requires learning a new architecture, and it isn't very portable unless the CPUs involved in the port implement asm or object level compatibility, and further, if you try to take advantage of that, you usually end up not using the cool features of later CPUs.
But in the end, it's just about as easy to write in asm as it is in C, it isn't significantly more granular on a function-per-line basis, though it certainly allows you to use the available CPU resources considerably more efficiently than most compilers can even get close to.
I recently had reason to go digging into the output of the GCC compiler when fed objective C... it was *horribly* inefficient. I was appalled at the resulting machine code, simply appalled. If someone had handed me that as a project in a "write a compiler" class, I'd have given it back with a remark like "you don't really want me to grade that, do you? You DO know that the CPU has more than one register you can use at a time, don't you? Try again." Yet this is the compiler that was used for production code in Apple's Leopard 10.5. Horrifying.
Then you're doing assembly all wrong. Assembly language is quite easy to write in if you structure it properly.
That said, it is an absolute bitch to read,
Asm can be easy to read IF you have appropriate commenting skills. I have 68000 asm code for PCB full-bore autorouting here that is still easy for me to read, and believe me, the task is pretty darned abstract, so that's saying something. Likewise, I have asm code for audio signal processing, very easy to read, etc. After writing asm for a while and over at least a few architectures, you learn what you have to to to keep things understandable and maintainable.
Slashdot Mirror
Speaking ONLY for myself; I read the FA, and I still see no significant reason to move away from standard c.
Know what would make me move? A syntax identical to the Python 2-series that compiled down to machine efficiencies similar to c. Now that's a beautiful syntax, a real step in the right direction. If I was writing it, I might be a little more strict about the indentation, so as to prevent things like lambda expressions, space/tab confusion, and single-line run-on, but overall, it's really, really nice as is. Add a good compiler and build in some portability, and I'd bite.
But... until then, I honestly don't think there is anything really worthwhile I could do in c++ that I can't do in c, generally at lower memory cost, higher speed, fewer "black boxes", and better portability. Which is not the same thing as saying there isn't anything unique to c++... just that the "good stuff" doesn't really add value I don't already have access to, albeit using much finer-grained techniques.
Objective c is pretty much the same... I find that the whole idea of objc is highly overrated, most of the added features are time- and memory-adding crutches... just a thin layer added to c that pressures you to use a messaging model you could have easily implemented yourself if you needed it, which you likely wouldn't -- if OSX wasn't chock full of it. :^)
On the Mac, I write an objc wrapper that talks to the OS, then write the core code in c. The only projects that I really write c++ for are those that arrive on my desk already written in c++, and which need my attention for porting, upgrades, etc. and even then... c++ methods end up wrapping c, generally speaking.
From my perspective, c++ and objc are both solutions seeking non-existent problems; solutions with fairly heavy penalties and which create overcomplicated implementation paradigms that take the focus away from the problem at hand. Too much emphasis on making programming "easy" and not enough on making it good. When I have to put the details together, I have to care about them. When I depend on the compiler to write part of the code for me, I'm going to get mediocre performance from a one-size-fits-all model without any real option to do anything about it. And I'm not just talking about code generation, although that's a problem too: I'm talking about managing the stack, making sure megabytes of cruft aren't glued to the application because some built-in capability incurs dependencies upon a whole series of frameworks or libraries, not having to fight the compiler-writers academic preconceptions about globals... I just prefer a finer degree of control, it suits me well.
And... yeah, I'd write in assembly if I could, there's another whole layer of speed, size and related benefits to be had there, but the portability issues, even within the same OS, are just too troublesome unless the code is for a controller where I know the hardware isn't going to change. Now *those* are fun projects.
Well, lets put it this way, then: Windows 8 will be a slow piece of shit. In addition, it looks like it will be incompatible with every piece of windows software currently out there, unless I completely misunderstand (they're telling us developers we can't use the old tools... so I take that to mean that the old tools won't produce usable code, therefore previously released code.... junked.)
The one thing of value Windows offered -- to me -- was long term backwards compatibility. With that gone, it's basically an entirely new OS, and you know what.. no thanks. I'd rather move to linux, which is very well established by comparison. Assuming my Mac somehow became dysfunctional.
I see. You're a member of the "just because it's a normal climate cycle, it won't happen because I don't like it" club. :^)
We're nearing the end of a cyclic interglacial. It's on the way, nothing you can do to stop it, pal. Warming LOL.
No matter what rep you work for, their office - through the auspices of a series of elected officials - is known to have completely and utterly broken their solemn oaths; known to have violated the constitution repeatedly and deeply; and you... you suggest we trust the current rep in that office, that we spend our time providing suggestions to them.
You're hilarious, you are.
But I'll tell you what. When the reps you work for rewrite the laws to respect the commerce clause for what it actually was meant to accomplish; when they reverse the ex post facto laws they've put into the legal system; when they stop trampling the bill of rights; maybe it'll be worth contacting them without bribe in hand.
Not that anyone sensible is holding their breath for any of that, mind you.
No, actually, as atmospheric CO2 increases, plants will grow more and more enthusiastically, increasing crop yield and quality, which in turn will directly influence human health issues in a positive direction.
Well, when there's a 3000 foot ice cliff looming over the upper US states again (instead of a 3001 foot ice cliff), and fleeing Canadians are the latest immigrant scourge, the warmers can just tell us that they told us so, it was global warming after all, and nyah-nyah, and etc. While the farmers in the south continue to enjoy higher crop yields. CO2 being a huge booster of plant metabolism and all.
You were able to flight test a pterodactyl, complete with hydrogen bladders? You are so AWESOME!
Welcome to slashdot! A quick primer on moderation:
Have fun on Slashdot!
No, you don't understand at all. My libs let me write to a model that doesn't carry the release-level baggage that your "better languages" do; consequently my release code is both faster and lighter than that produced with, for instance, objc or c++, etc. But during development, I receive all manner of feedback if anything goes wrong, which bulletproofs the things I'm doing BEFORE they are let loose without protection, lightweight and fast. Your "better language" is always dragging around heavy and clumsy memory managers that are generalized and not optimal; my memory code is much better because it's always case-specific. And it doesn't waste the user's resources. And there's never any GC stumbling about, either.
No. I'm taking the position that my code is more maintainable by me than other people's, and the only reasons I say that are because (a) I have the source and (b) I wrote the source, so I understand it intimately. For any framework where I don't have the source, fixing a problem *is* a problem. Trying to get Apple to fix a framework bug is like trying to push a Sherman tank uphill with a wet noodle. If I do have the source, for instance, lets say the JPEG libs, there can be massive slogging around trying to figure out why, for instance, setting the chroma resolution to 1x1 instead of 2x2 doesn't work in the new lib, but did in the old lib. Whereas if I use my jpeg library, not only do I have control over this (and it continues to work), but I can also load all those jpeg variants that won't load with the standard IJPG libs and I can let a configurable number of cores loose on different compression blocks, which gives me a huge speed advantage over, say, the IJPG libs. Likewise, if I use my treeview, the treeview works properly. If I use theirs... well, just Google it, you'll see the problems, which are many. Their treeview is a nightmare collection of screwups. And so on.
No, I'm not. Believe it.
Oh, they're going to run into real trouble here, McDonald's has a patent on this.
Yes. Unfortunately, it is also very bad advice.
The exposed nail gets hammered down, and very much so in US employment today.
The current American mentality is witchhunt first, then never, ever forgive. Felon? Employment-wise, you're hammered. Forever. Sexual *anything* to do with the law? Employment-wise, you're hammered. Forever. Anything that the social retards think isn't Good for the Children? I'm talking drinking, drugging, tattoos, piercings, partying, "planking", nudity of any kind, shooting, marching for any particular cause, flash mobbing, pranking, sexting, imitating the cognitively-impaired people on Jackass, extreme sports... or even being THERE when someone ELSE is doing any of these things... employment-wise, you're hammered.
And if, for some reason, things aren't quite that bad yet, don't worry, they'll very likely pass ex post facto laws to make it so later; just as they already have with guns and the various lists -- do not fly, do not sell to, violent/sexual offender, terrorism. And they'll conflate ridiculous things too - 17-year-old == child == peeing in bush, etc. You can do the most innocuous thing that you think is perfectly ok -- like photograph your cute little infant in the tub -- and end up with your mug shot right next to Victor the Vaginal Butcher, unemployable and forced to move into a box under that bridge downtown you've been throwing your coffee cups over the past few years.
So... you don't appreciate StupidBook becoming a threat to your job and you life and your family? Get out before it happens. Delete everything on your page before you go, and un-friend everyone. It's all you can do. It won't be enough - this is truly becoming a permanent record society that never, ever forgives, criminalizes the ridiculous, and no longer even gives lip service to the ideas of forgiveness or rehabilitation - but it's a start in the right direction.
Also - speaking as a photographer of many years - stop photographing people. Just stop. Nature, old, non-governmental architecture, that's the thing to shoot. Photography is turning into the next minefield. Same thing goes for video, if you're into video. Not just because it might harm you; but because it also might harm them. You might photograph someone in a place they really would prefer others not know they were, for whatever reason... you might catch that funny drunk guy, share the pic, and cause him to lose his job and livelihood and really, really hurt his entire family... or you might shoot that lovely government building you paid for and find yourself answering very hard questions from very hard people about why there is a bottle of bleach under your sink and ammo for your 22 cal. match rifle in your closet, said people showing up right at your job, complete with warrant from their pet oath-breaking judge. Followed immediately by your very own pink slip, because employers are hugely threatened by such events. And now you're unemployable. Welcome to America 2011.
sure am. :)
Why act? Get paid to stand on a stage or in front of a camera, pretend you're someone you aren't, and act out fictional relationships, situations, times... so people can lose themselves in the fantasy... is that part of your "no one would do THAT" idea? I'm guessing not.
What about a masseuse? Get paid to rub someone's body, all over, to make them feel better. That ok in your ideal society? I'm still guessing, yes. Or a physical therapist: rubbing to repair, among other things. Exercise, range of motion, that all sure feels good (I'm a martial artist... very familiar with the pleasures of working the body from either end.) Again, are those things any part of your "gee, no one would do THAT" idea? I'm still guessing not.
So we've established that some people are ok with faking who they are for fun, pleasure and recompense; others are ok with extended, long term body contact by appointment, with oils, atmosphere and more, to make you feel better, again for recompense. And this is all perfectly ok. Right? Your imaginary ideal society would allow acting and massage and physical therapy, yes?
Well, a sex worker does both of these. There may be even less body contact than with a masseuse; there may be less detailed acting than you'd see on stage or film (or not, if you've chosen well.) So what's the problem? I'll tell you: the problem is social conditioning; the problem is in you. Accept the performance as it is delivered, as an exchange, and you'll be fine. Try to convince yourself you know what's going on in the other person's head, and it's all bad, and you know better than the performer. that your payment has bought something you weren't offered... and you're simply proving you're a pompous ass. Otherwise, enjoy the performance, treat the performer with respect, appreciate the time and energy and skill, pay what is due, and move along.
It is simply pitiful watching you and your post's parent trying to paint a fixed morality picture -- in your case, an entire society -- for people who don't agree with you. Remember: everyone is different. That means you don't know what's going on in their heads, and you don't know what is ideal. Period. There are people who turn to prostitution (and McDonalds) out of desperation; there are others who are there because it suits them just fine. Anyone who is doing anything out of desperation should work to get clear; anyone who is doing what they want in a consensual and informed manner -- regardless of what it is -- has absolutely no need of your clueless moralizing.
Sex definitely isn't the one-dimensional thing you've been conditioned to think it is. Getting beyond that illusion will instigate beneficial personal growth. Count on it.
Also, good looks, athleticism, intuition, a desirable figure, a kind heart... these are perfectly fungable assets. You have no right to declare any of them off limits, in any combination.
That is simply utter nonsense coming from someone who is baffled about sexuality. Sex can be a service; a payment; a gift; a kindness; an act of love; combinations thereof and more. And furthermore, it is normal for it to be all of those things. Your limited view of sexuality has completely blinded you to the many dimensions that exist outside of your concept of people only engaging in the act for reasons you approve of. Luckily, what you approve of is wholly irrelevant.
Python 2.x comprises an awesome language series. A real shame about python 3's incompatabilities, but we still have python 2.x, so it's far from a total loss. And perhaps ol' Guido will wise up and turn back to maintaining a properly compatible upward development course with the 2.x series. One can hope.
Huge fan of Python, myself. This is my python code for instance... it's an aurora detection and prediction system that sends me an SMS whenever I need to get out there with my camera. And as you can see, it works for me. Uses PyEphem and PIL, otherwise comprised of my code, my meter and web scraping libraries, etc.
No. It's not harder. It's just different. Java poses some huge challenges at times; to be "good", you should be able to say you can meet them. c challenges are very different, and frankly, they're simpler, but again, to be good, you still have to meet them. There are some traps -- the "standard" (K&R and derived) code formatting puts an instant hurt on comprehension, and a lot of programmers have fallen for that because no one has taken the time to show them there is a better way -- many of them are now habituated and can't get beyond it.
The only languages I've ever run into that were legitimately "harder" brought a different type of challenge to the table: APL, for instance, is actually a harder language because you have a lot of non-intuitive learning to do, and you need to make it intuitive if you're going to be any good. It's like learning Klingon.
Some languages form a natural progression of learning: asm to forth to c is a very natural progression, for instance, even though one is direct, one can be interpreted, compiled or byte-coded and is RPN-ish to boot, and the last is almost always primarily algebraic and compiled. So it's an easy learning curve. There's nothing easy about APL, it'll make your brain bleed. Lisp is no picnic, either; visually speaking, it's a bitch, and that makes it difficult to learn. Python is so easy to learn -- and powerful -- it's almost ridiculous. Perl is powerful, but hugely annoying in its non-intuitive symbol-soupness and the first time you try to deal with Other People's Code in perl, you'll learn why the best programmers moved right over to Python as soon as they understood what it offered.
Anyway, no, Java and c... not really different in terms of getting good. Perhaps what has really caught your attention is that there aren't that many good programmers, period. That's where languages with training wheels - memory, lists, dictionaries, the lovely exception handling exemplified in python -- help them along far enough so they can make production code anyway. The resulting apps are inevitably slower, larger, and more fragile than what a good programmer would have made, but you know, they mostly do the job, and that's what the poor public has become accustomed to.
I start the "Island HD" game on my ipad, it cranks for a minute, then crashes. Yep, pretty much par for the course. I start it again, this time it runs. Looks like the OS had a little more memory in a single chunk that time... I start the NPR news app, it can't get to the server, it crashes in the middle of loading a news item. Same thing for my Pulse news reader. Can't get to an article... crash. Chess with Friends: start it, it's a toss up if it'll crash or not. Once running, it appears stable, though. On the Mac, every time a cron job starts, OSX pukes an (incorrect) error message to the console. I use cron a lot, so that got really old... and so I fixed it. And then we get into issues where some fool thinks its ok to constantly prod you to "connect to facebook" and leaves you no way to say, "I'm not on idiot facebook, nor will I ever be, so stop doing that." Just lousy programmers everywhere.
Yeah, that's the main problem. Not c or java.
See, what you've just admitted is simply that you failed to even try to solve the problem. Like most things in programming, it's amenable to effort, and there are significant rewards.
First thing I do on a new project is incorporate my development memory code; I get pools, cached pre-allocators, null pointer checking prior to every use, prior to deallocation, and on allocation; memory consumption tracking both in amount and allocate/deallocate counters, reference counting, over- and under-run barriers, named, unfreed capture and unfreed re-allocation trapping, barriered arrays and exposed (defeatable) array accessors, and a good deal more. This adds about 50k to the target executable during development.
Then, when it's release time, I simply switch to the release version, which recompiles into lean, mean memory handling, about 3k, knowing that any problems -- which, frankly, after decades of doing this, are few -- have already been caught. Exposed accessors and so forth are still there, no overruns happening, etc. So I don't spend time "doing memory management"; No null pointers, no buffer overruns, no issues at all, and no particular work to make it all happen. Code once, enjoy the many, many benefits thereafter. Completely under control. And that goes for a lot of other things you might consider "c issues", too -- over the years, you (well, I) learn to solve problems in a way that moves forward with you. These are *tiny* chunks of code, not these massive frameworks from Waste-O-Rama, Inc.
In the end, I produce a faster, leaner, more efficient app that saves the user time with every action; is much easier to maintain (either fix or upgrade) because it doesn't depend on external libraries and frameworks I don't have control over; saves download time simply because it's much smaller than a comparable C++ etc. application; doesn't unethically trade the user's application space for any perceived development effort savings, and is known to have a very high degree of correctness on its way out the door. If someone finds a problem, I can fix it in minutes, because there are no black boxes. Users like that, too... email in, fix comes back in half an hour. Kind of sets them on their heels, for some reason... guess they're used to something else, eh?
I even get to use all manner of OO techniques - objects with built in functions, allocators, class functions, object functions, etc., but the difference is, I have complete control over them; I'm not at the mercy of the compiler, framework, or otherwise private libraries, because they're built using my own code and methods. I'm not tied to any particular GUI generator (that's a real issue in Apple's OSX), and I don't have to worry about dragging little lines around to connect my objects -- that's all done "in your face", in code -- no hidden black box nonsense. My buddy back on the east coast spent many hours last week trying to incorporate Apple's treeview control... I have a pile of email from him complaining about the built-in bugs... I just LOL'd and showed him my treeview library. Bugfree and more functional than Apple's, anyway. Nothing beats having your own code. Other People's Code is almost always an invitation to trouble, and that is especially true if it is some major company's, because they simply are not going to be responsive to your needs.
And as to race conditions... I write real time, multi-threaded signal processing code. I invented some of the current AFSK modes. My latest project is a multicore aware, user-core-utilization selectable image processing suite -- in beta now (see it on the middle two monitors?) -- that makes Aperture look like a box of slow, clumsy crayons, but is a fraction of its size and offers *far* more in terms of functionality, even incorporates an astrophoto processing system. About 99% c, the rest is an obj-c application wrapper. I think I might know a little bit about how not to trample my own toes in this regard.
No
Cite? Data? LOL.
That would very much depend on the compiler. I just looked at the code output of the GCC compiler when fed objective C (very close to c), and trust me, the code was HORRIBLE. GCC is a pretty modern compiler, as things go, and there's one case where code generator optimization -- and I use the term extremely freely here -- was apparently not even attempted, or if attempted, is a mad fail.
I'm sure, speaking as a very experienced asm programmer, that some compiler, somewhere, someday, could outcode me on some given architecture (and more likely on architectures that are slovenly, like Intel's usual weirdness), but I think it's worth reporting that I've not yet encountered said compiler.
The most powerful tool -- and the one with the most precision -- is asm. And it certainly isn't for everyone. What YOU probably meant to say is "C++ and other tools of increasing abstraction aren't for everyone."
JFC!!! mod parent up UP UP for the spot-on "performance is not important" rant
Actually, I think we're dealing with two completely different definitions of "close to the iron here". Nothing wrong with yours (low level architectural feature access), but yours isn't the usual meaning, either. The usual meaning is that a line of c produces easily predictable results for a particular architecture, and therefore someone who knows the CPU architecture, compiler habits, and c itself can do a good job of keeping the code efficient within the bounds of what the compiler does. This becomes more and more difficult as the compiler sophistication upscales, eg with C++, and that's why c, rather than c++, gets the accolade.
Also, an argument could be made for some versions of C having low level architectural feature access by virtue of simply being able to say #asm at any time and properly utilizing the compiler's version of the #asm/#endasm interface. Although as far as I'm concerned, if you're going to do that, you probably should have been writing in asm anyway...
ASM is far higher than "molecular level", in fact, it's not all that far off from C (which is one of the benefits of C.) The real disadvantage of ASM isn't what the uninformed think it is -- the bogus claim that it doesn't get much done per line -- the main disadvantages are that each CPU requires learning a new architecture, and it isn't very portable unless the CPUs involved in the port implement asm or object level compatibility, and further, if you try to take advantage of that, you usually end up not using the cool features of later CPUs.
But in the end, it's just about as easy to write in asm as it is in C, it isn't significantly more granular on a function-per-line basis, though it certainly allows you to use the available CPU resources considerably more efficiently than most compilers can even get close to.
I recently had reason to go digging into the output of the GCC compiler when fed objective C... it was *horribly* inefficient. I was appalled at the resulting machine code, simply appalled. If someone had handed me that as a project in a "write a compiler" class, I'd have given it back with a remark like "you don't really want me to grade that, do you? You DO know that the CPU has more than one register you can use at a time, don't you? Try again." Yet this is the compiler that was used for production code in Apple's Leopard 10.5. Horrifying.
Asm can be easy to read IF you have appropriate commenting skills. I have 68000 asm code for PCB full-bore autorouting here that is still easy for me to read, and believe me, the task is pretty darned abstract, so that's saying something. Likewise, I have asm code for audio signal processing, very easy to read, etc. After writing asm for a while and over at least a few architectures, you learn what you have to to to keep things understandable and maintainable.