> I was working with Confluence (write [functional!] Scheme-ish code
That's not the computer. That's your LISP programming language that you use to program the computer. Programming languages can be functional, at the cost of some overhead. Your FPGAs are still algorithmic, they do things sequentially, one thing per clock cycle.
> if you express a function that evaluates (at "compile" time) as recursing 15-deep, > it can replicate that function 15 times so that it all happens in one clock cycle
Sure, you can write multiprocessing directives with a functional language too. In an algorithmic approach you would iterate over the available processors and spread the work among them, which is what the hardware would actually do.
> For example, in a message-passing multithreaded environment, messages are often > created by one object, passes through a message queue, and destroyed when a pool of > thread, which often is part of another object, has finished processing it.
Yes, you might do that, but my pattern would still work better even here. Create a message queue object which will be the owning container. Queue messages with msgq.push_back (new Message). Read messages with msgq.front()->Method(), then pop_front (which will delete it).
However, I would take it one step further, as I did in the code I'm presently working on: marshal the messages into a bytestream and queue messages as memory blocks. That way you can not only spread the work among threads, but also among different processes or even over many computers over a network. This is basically how CORBA and DCOM work.
Things suddenly got uglier, didn't they? But wait, what if you need to call a function with an argument? Gotta use a bind2nd adaptor to wrap it, and then it becomes:
Wait 'till you try to explain to some maintaining programmer how to untangle that! Oh, and just for laughs, try to debug this thing. Put an assert in SetParameter, and you get a lovely callstack from gdb:
(gdb) run Starting program:/home/user/tmp/tes tes: tes.cc:18: void CComponent::SetParameter(int): Assertion `!"Check out the callstack!"' failed.
Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () Current language: auto; currently c (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d36126 in *__GI_raise (sig=6) at../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0xb7d37b40 in *__GI_abort () at../sysdeps/generic/abort.c:88 #3 0xb7d2f610 in *__GI___assert_fail (assertion=0x6 <Address 0x6 out of bounds>, file=0x6 <Address 0x6 out of bounds>,
line=6, function=0x80495a0 "void CComponent::SetParameter(int)") at assert.c:83 #4 0x080485f6 in CComponent::SetParameter (this=0x804b008, arg=42) at tes.cc:18 #5 0x08048ac3 in std::mem_fun1_ref_t<void, CComponent, int>::operator() (this=0xbfe2cacc, __r=@0x804b008, __x=42)
at stl_function.h:826 #6 0x08048ae8 in std::binder2nd<std::mem_fun1_ref_t<void, CComponent, int> >::operator() (this=0xbfe2cacc, __x=@0x804b008)
at stl_function.h:446 #7 0x08048b0c in std::for_each<__gnu_cxx::__normal_iterator<CCompon ent*, std::vector<CComponent, std::allocator<CComponent> > >, std::binder2nd<std::mem_fun1_ref_t<void, CComponent, int> > > (__first={_M_current = 0x804b008}, __last=
{_M_current = 0x804b00c}, __f=
{<> = {<No data fields>}, op = {<> = {<No data fields>}, _M_f = {__pfn = 0x80485c4 <CComponent::SetParameter(int)>, __delta = 0}}, value = 42}) at stl_algo.h:158 #8 0x08048740 in main () at tes.cc:26 (gdb)
Now that's something to scare newbie programmers with! Oh, and forget about putting a breakpoint inside the loop; templated functions aren't targetable until executed.
> in some code I need to maintain then to encounter > for(i = 0; i < components.count(); ++i) components[i].disable()
So why not just use an iterator loop? for_each does not have a monopoly on it:
foreach (compvec_t::iterator, i, components)
i->disable();
(foreach is a macro I wrote because I use this construct so often)
> first form permits, for instance, components to be a linked list or even a hash. > The second is implementation-dependent and if you change the underlying data > structure, you'll have extra work to refactor.
If you use iterator loops, this wouldn't happen to you.
> I once worked, changing all instances of SomeObject* to auto_ptr > eliminated altogether 35 bugs we had lurking in the BTS for a long, long time, > with less than one day of work (strange, delayed, errors were suddently > transformed in EARLY null-pointer dereferences
Why were you using SomeObject* in the first place? When I was advocating moderation in the use of auto_ptr, I wa
> Not understanding something is one thing, but not understanding something > so let's reject it as being "elite-ivory-tower"
I did not say I did not understand it. I said I did not like it. I do not like it because it does not fit with the reality of computer operation, as discussed below.
> Reality is reality. Algorithmic or Functional are just ways people look at it.
On the contrary, you can see reality being algorithmic. Things happen one after another. To type "algorithmic", you depress a, l, g, etc. in order; you don't declare a set of letters, fill it with appropriate values and throw it at the computer. When you receive a specification for your program, it will say something like "get this from the user, then do this, then do that, then print out the result". No specification is ever written in functional notation outside the academic world.
More importantly, the computer itself works algorithmically. It does one thing, then another. No computer has ever worked functionally, and no computer ever will. All of them will decode and execute a sequence of instructions, and if you refuse to write your code likewise, you're only adding translation overhead.
Even in the hallowed halls of science overuse of the functional notation creates serious problems. The entire hodge-podge nonsense we call quantum mechanics stems from the attempt to describe a complicated system as a function. Instead of trying to get a set of time-value maps for the whole system, it would be more appropriate to look at the system's constituent parts and algorithmically simulate them through time. That way you wouldn't get any "spooky action at a distance", stuff being there and not there at the same time, and all other equally ridiculous denials of reality.
> I advise you, that your use of the common peoples' fear for mathematics > in your arguments is not going to help.
I wasn't using that argument, but, now that you mention it, it is a reasonable one. Most programmers couldn't care less about higher mathematics, and, even if they were forced to study it in college, they likely have forgotten it all by now. Computer algorithms require minimal mathematical background. The most I ever used was a bit of calculus to write scan-conversion routines. So, whether from lack of practice, or from lack of interest, most programmers will prefer you didn't drag them into the world of useless mathematics. (and I use the word literally here)
> Templates, being code generators, differ by nature to hand-tuned codes. > So your code generates only 33 instructions vs the template's 88. Great > - now tell me - which architecture? What compiler?
That is quite irrelevant in this case. istream_iterator notation generates extra code for reasons that will not go away no matter how hard you try to optimize it. Yes, I might be able to write an istream_iterator that would have no overhead over my iterative version, but it will not be standard compliant. The istream iterator has to read on construction; it has to store the read value; it has to be constructed, since it must keep a reference to the source stream; it has to handle special cases, like the end-of-file, and the subsequent conversion to the end iterator value. However good you might be at optimization, you will not be able to discard these and still be compliant with the specification.
Also, which compiler or architecture you use will not make all that much difference in the size of the compiled code. I guarantee you that your functional copy will never generate smaller code than my iterative loop, no matter what compiler you use or what architecture you compiler for. There is a certain amount of work to be done, and my version does less work. It is as simple as that.
> And before you count the instructions, did you realize that this code is waiting > for keyboard inputs, therefore what you're doing is unnecessary (and obviously > premature) optimization?
> copy (istream_iterator(cin), istream_iterator(), back_inserter(v)); > > is just plain beautiful IMH?O.
I'm sorry, but I just can't agree. It might appeal to a mathematician who wants to see everything use functional notation and hates every language except lisp, but to a non-abstract-elite-ivory-tower-mathematician this is absurd. cin is not an array of integers and the use of the adapter obfuscates the fact that you are using a conversion from a char array to an int. The back_inserter also makes it harder to see where the data is going by losing "v" in it. Many would also frown at it for taking a non-const reference, although since it is a standard adaptor it is probably ok.
C++ programmers are often unnaturally attached to efficiency and have to be watchful for template bloat. Your copy generates 88 instructions, whereas an equivalent iterative solution is only 33 instructions long, most of them belonging to the inlined push_back. Not only is the generated machine code smaller, but the source code is smaller as well, and is far more readable, making the algorithm obvious at a glance to any procedural programmer, who make up the majority outside the hopelessly out-of-touch with reality academia.
int n; while (cin >> n)
v.push_back (n);
Academics love integer and float arrays because that's what they usually work with. Scientific simulations produce data in that form and require processing programs that take something from a data file, crunch some numbers, and output something to cout. In the real world people work on user interfaces, databases, and other complicated things, where one normally works with arrays of objects rather than numbers. If you ever tried to apply a functional algorithm to a vector of objects, trying to manipulate some member variables or call a member function, you would know that the result is so hideous that it isn't even worth considering. There is a reason people prefer iterative solutions; they are how the real world works. Reality is algorithmic, not functional, and so are user specifications for the things they want done. Trying to cram them into an abstract mathematical functional model is insanity.
> Use, carefully, and always when possible, smart pointers. > Remember std::auto_ptr is your best friend
Most of the time, no. While I would not deny the utility of auto_ptr in localized situations manipulating the object state during reallocation, its constant use indicates lack of understanding of object lifecycle in the program. It is fashionable in Java to create objects left and right, without consideration of who is supposed to own them. Hey, just let the garbage collector take care of it! Who cares how long the object lives? Obviously, such immature mentality produces plenty of memory leaks for which Java is so infamous. In a good design object ownership is strictly defined. Objects belong to collections that manage their lifecycle. There ought to be no "dangling" objects that just "hang there". If you don't know to which collection the object belongs, you have no business creating it. If you think your objects are "special", you haven't thought beyond their internal functionality or considered where it fits in your overall design.
> Question 2: How can I actually implement such a decoupling? > I would use a simple, socket-base, take-my-data, gimme-my-results scheme
And thereby slowing your program to a crawl? There is a reason people use CORBA and the like: those frameworks optimize distributed object calls to avoid network hits, often being able to reduce the overhead to be equivalent to a virtual function call. Furthermore, networked applications have their own set of complexities and security considerations. You get to keep an open port somewhere, handle authentication (becase wherever there's an open port, there will be malicious connections), and extensive data validation (for the same reason). While these problems are applicable to dis
I, for one, welcome our new Flash killing overlords. After all, anything that promises to kill off flash must have been made by a most honorable and considerate person, who wishes nothing more than to spare us from the many, many pains of the hostile landscape of the web.
If you actually look at the code you'll see plenty of bad coding practices. vvvv and uuuuu as variable names? malloc and free in C++ code? Cut-n-paste code where a loop ought to be? It looks like something that I might find on the "Daily WTF" site.
If "Pentium" is a fifth generation processor, then the next logical name should indicate a sixth generation processor. "Sexium" is just such a hot name.
I think "sharp" is not too appropriate...
on
Demise of C++?
·
· Score: 2, Funny
... for a language that is just a hash of things created by random pounding on the keyboard.
We just got tired of being insulted
on
Demise of C++?
·
· Score: 5, Insightful
We, C++ programmers, just got tired of being insulted all the time, so we don't talk much any more. After all, every time we mention C++ we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to writing code. If you don't want to listen, you are only hurting yourselves and your employers.
The mafia forms a political party, named "The Lovers of the Italian Opera" dedicated to legalization of loan sharking, money laundering, drug dealing, theft, and murder.
And, of course, I already used it to read Slashdot. Oh, darn...
Want colors and blinking text in your output?
on
Why Use GTK+?
·
· Score: 1
> It has no support whatsoever for colors or blinking text!
<shamelessplug> Want colors and blinking text in your output? Use the Useful Terminal I/O Library! You get all that and the other things you have been missing since you traded DOS and conio.h for Linux. </shamelessplug>
Well, as a C++ programmer, I am quite used to hearing how C++ is evil because of all the things it can do. Therefore, I am as justified as they are in saying that C++ is better than genetic code for the following reasons:
Genetic code is too low-level. While C++ comes with a standard library defining containers, iterators, and common algorithms, in genetic code you have to do everything from scratch. In quaternary. With 3D objects. Talk about a learning curve!
Genetic code has no garbage collector, and not even a simple malloc. In fact, you have to write self-modifying code to avoid memory leaks or dangling references. This makes it very difficult for the beginning programmer to write good code, and encourages bad practices.
Genetic code is not object oriented. You have to do horrible hacks to encapsulate private information or define interfaces to it. Most programmers just use a "signals-and-slots" method to pass messages, resulting in spaghetti code rivaling the worst abuses of goto.
Genetic code is too flexible. If you thought bad C++ code was hard to understand due to operator overloading, wait 'till you see the things a bad programmer can do with genetics! And, while in C++ the worst that can happen is a crash, bad genetic code could eat you.
Genetic code takes longer to develop for. You have to write lots and lots of code to duplicate even the simplest C++ line. Furthermore, compilation times totally suck, approaching twenty years for complex programs!
Genetic code has an arcane syntax, leftover from the early days of evolution. Just imagine, we're still using constructs nearly three billion years old! If you thought having some C in C++ was bad, wait 'till you see the archean leftovers you are forced to use in your eukaryotic cells!
Genetic code is dynamically typed and favors the "duck typing" philosophy. This creates an enormous amount of security holes, where special ducks ("poisons") with appropriate appearance but malicious behaviour could be introduced into the system.
Genetic code is hard to debug. Having no debugger, one has to rely on contrived printf-like trace statements. Unlike printf, the genetic equivalents are limited in number and expressiveness, sometimes making it impossible to figure out what is wrong.
Genetic code is a bloated pig. Just imagine, you need trillions of bits to define a simple organism, while in C++ I can code NPCs in under a hundred lines of code.
Genetic code VM is slow. Perhaps not as slow as Java, but it still takes milliseconds to do even simple operations. We could all think so much faster if we were written in C++.
Java applications are usually supposed to run in a VM on the user's machine, which is problematic because it requires both support for it and good security. In many places Java is locked out because people heard the VM was insecure. I have never enabled the darn thing at all and never saw any Java app I wanted badly enough. Add to that the fact that embedded Java apps don't look like HTML and they don't look like the OS, and it is a recipe for disaster.
Server-side Java VMs are probably shunned because of their memory footprint, which is too large to allow a heavy load. That leaves lighter scripting languages like Ruby, which are used mostly because there really isn't anything better.
As for C++, it is hard to do web development in it due to lack of libraries. People also have this irrational fear of the language, fueled by decades of unjustified FUD. And, C++ programmers really would rather write desktop applications, even though the current fad is against them. IMO, this web application fad will blow itself over, just like all the previous attempts to make thin clients. The approach is particularly ridiculous now that even a $300 computer is more than enough for most mundane tasks. What will come after it? We'll either fix the desktop so that people will stop trying to find "solutions" like the web application, drop into a dark age, or whatever.
Saying "information wants to be free", even if they actually did so, would not promote music piracy. Music is not information, it is art, and art usually does not want to be free. Price reflects quality (in an ideal world, at least), and good artists are always going to be in demand, and consequently, in money.
28%? Come on! Which university did they go to? Some girls college, no doubt. In my graduating class there were two women and a about a hundred men, so that works out to two percent or so.
Slashdot Mirror
So you are saying that "we'll make the budget deficit 2 times smaller", really means newBudgetDeficit = oldBudgetDeficit * 2?
> I was working with Confluence (write [functional!] Scheme-ish code
That's not the computer. That's your LISP programming language that you use to program the computer. Programming languages can be functional, at the cost of some overhead. Your FPGAs are still algorithmic, they do things sequentially, one thing per clock cycle.
> if you express a function that evaluates (at "compile" time) as recursing 15-deep,
> it can replicate that function 15 times so that it all happens in one clock cycle
Sure, you can write multiprocessing directives with a functional language too. In an algorithmic approach you would iterate over the available processors and spread the work among them, which is what the hardware would actually do.
> For example, in a message-passing multithreaded environment, messages are often
> created by one object, passes through a message queue, and destroyed when a pool of
> thread, which often is part of another object, has finished processing it.
Yes, you might do that, but my pattern would still work better even here. Create a message queue object which will be the owning container. Queue messages with msgq.push_back (new Message). Read messages with msgq.front()->Method(), then pop_front (which will delete it).
However, I would take it one step further, as I did in the code I'm presently working on: marshal the messages into a bytestream and queue messages as memory blocks. That way you can not only spread the work among threads, but also among different processes or even over many computers over a network. This is basically how CORBA and DCOM work.
> for_each(components.begin(), components.end(), _1.disable())
It is never that simple. The fact that you can't do what you've typed is one of the reasons I dislike it so much. What you really need is:
Things suddenly got uglier, didn't they? But wait, what if you need to call a function with an argument? Gotta use a bind2nd adaptor to wrap it, and then it becomes:
Wait 'till you try to explain to some maintaining programmer how to untangle that! Oh, and just for laughs, try to debug this thing. Put an assert in SetParameter, and you get a lovely callstack from gdb:
Now that's something to scare newbie programmers with! Oh, and forget about putting a breakpoint inside the loop; templated functions aren't targetable until executed.
> in some code I need to maintain then to encounter
> for(i = 0; i < components.count(); ++i) components[i].disable()
So why not just use an iterator loop? for_each does not have a monopoly on it:
(foreach is a macro I wrote because I use this construct so often)
> first form permits, for instance, components to be a linked list or even a hash.
> The second is implementation-dependent and if you change the underlying data
> structure, you'll have extra work to refactor.
If you use iterator loops, this wouldn't happen to you.
> I once worked, changing all instances of SomeObject* to auto_ptr
> eliminated altogether 35 bugs we had lurking in the BTS for a long, long time,
> with less than one day of work (strange, delayed, errors were suddently
> transformed in EARLY null-pointer dereferences
Why were you using SomeObject* in the first place? When I was advocating moderation in the use of auto_ptr, I wa
Well, if you want to do that, it is easier to use for:> You have 5 lines (including enclosing braces) where std::copy needs 1.
As much as I like one-liners, I would still prefer three short lines to one really really long one.
> when you factor in the implicit boolean conversion in the while clause
You might think of it as a return value instead, reading the while as "while you can do cin >> n, push it back".
> Not understanding something is one thing, but not understanding something
> so let's reject it as being "elite-ivory-tower"
I did not say I did not understand it. I said I did not like it. I do not like it because it does not fit with the reality of computer operation, as discussed below.
> Reality is reality. Algorithmic or Functional are just ways people look at it.
On the contrary, you can see reality being algorithmic. Things happen one after another. To type "algorithmic", you depress a, l, g, etc. in order; you don't declare a set of letters, fill it with appropriate values and throw it at the computer. When you receive a specification for your program, it will say something like "get this from the user, then do this, then do that, then print out the result". No specification is ever written in functional notation outside the academic world.
More importantly, the computer itself works algorithmically. It does one thing, then another. No computer has ever worked functionally, and no computer ever will. All of them will decode and execute a sequence of instructions, and if you refuse to write your code likewise, you're only adding translation overhead.
Even in the hallowed halls of science overuse of the functional notation creates serious problems. The entire hodge-podge nonsense we call quantum mechanics stems from the attempt to describe a complicated system as a function. Instead of trying to get a set of time-value maps for the whole system, it would be more appropriate to look at the system's constituent parts and algorithmically simulate them through time. That way you wouldn't get any "spooky action at a distance", stuff being there and not there at the same time, and all other equally ridiculous denials of reality.
> I advise you, that your use of the common peoples' fear for mathematics
> in your arguments is not going to help.
I wasn't using that argument, but, now that you mention it, it is a reasonable one. Most programmers couldn't care less about higher mathematics, and, even if they were forced to study it in college, they likely have forgotten it all by now. Computer algorithms require minimal mathematical background. The most I ever used was a bit of calculus to write scan-conversion routines. So, whether from lack of practice, or from lack of interest, most programmers will prefer you didn't drag them into the world of useless mathematics. (and I use the word literally here)
> Templates, being code generators, differ by nature to hand-tuned codes.
> So your code generates only 33 instructions vs the template's 88. Great
> - now tell me - which architecture? What compiler?
That is quite irrelevant in this case. istream_iterator notation generates extra code for reasons that will not go away no matter how hard you try to optimize it. Yes, I might be able to write an istream_iterator that would have no overhead over my iterative version, but it will not be standard compliant. The istream iterator has to read on construction; it has to store the read value; it has to be constructed, since it must keep a reference to the source stream; it has to handle special cases, like the end-of-file, and the subsequent conversion to the end iterator value. However good you might be at optimization, you will not be able to discard these and still be compliant with the specification.
Also, which compiler or architecture you use will not make all that much difference in the size of the compiled code. I guarantee you that your functional copy will never generate smaller code than my iterative loop, no matter what compiler you use or what architecture you compiler for. There is a certain amount of work to be done, and my version does less work. It is as simple as that.
> And before you count the instructions, did you realize that this code is waiting
> for keyboard inputs, therefore what you're doing is unnecessary (and obviously
> premature) optimization?
First, you should note that I
>
> is just plain beautiful IMH?O.
I'm sorry, but I just can't agree. It might appeal to a mathematician who wants to see everything use functional notation and hates every language except lisp, but to a non-abstract-elite-ivory-tower-mathematician this is absurd. cin is not an array of integers and the use of the adapter obfuscates the fact that you are using a conversion from a char array to an int. The back_inserter also makes it harder to see where the data is going by losing "v" in it. Many would also frown at it for taking a non-const reference, although since it is a standard adaptor it is probably ok.
C++ programmers are often unnaturally attached to efficiency and have to be watchful for template bloat. Your copy generates 88 instructions, whereas an equivalent iterative solution is only 33 instructions long, most of them belonging to the inlined push_back. Not only is the generated machine code smaller, but the source code is smaller as well, and is far more readable, making the algorithm obvious at a glance to any procedural programmer, who make up the majority outside the hopelessly out-of-touch with reality academia.
Academics love integer and float arrays because that's what they usually work with. Scientific simulations produce data in that form and require processing programs that take something from a data file, crunch some numbers, and output something to cout. In the real world people work on user interfaces, databases, and other complicated things, where one normally works with arrays of objects rather than numbers. If you ever tried to apply a functional algorithm to a vector of objects, trying to manipulate some member variables or call a member function, you would know that the result is so hideous that it isn't even worth considering. There is a reason people prefer iterative solutions; they are how the real world works. Reality is algorithmic, not functional, and so are user specifications for the things they want done. Trying to cram them into an abstract mathematical functional model is insanity.
> Use, carefully, and always when possible, smart pointers.
> Remember std::auto_ptr is your best friend
Most of the time, no. While I would not deny the utility of auto_ptr in localized situations manipulating the object state during reallocation, its constant use indicates lack of understanding of object lifecycle in the program. It is fashionable in Java to create objects left and right, without consideration of who is supposed to own them. Hey, just let the garbage collector take care of it! Who cares how long the object lives? Obviously, such immature mentality produces plenty of memory leaks for which Java is so infamous. In a good design object ownership is strictly defined. Objects belong to collections that manage their lifecycle. There ought to be no "dangling" objects that just "hang there". If you don't know to which collection the object belongs, you have no business creating it. If you think your objects are "special", you haven't thought beyond their internal functionality or considered where it fits in your overall design.
> Question 2: How can I actually implement such a decoupling?
> I would use a simple, socket-base, take-my-data, gimme-my-results scheme
And thereby slowing your program to a crawl? There is a reason people use CORBA and the like: those frameworks optimize distributed object calls to avoid network hits, often being able to reduce the overhead to be equivalent to a virtual function call. Furthermore, networked applications have their own set of complexities and security considerations. You get to keep an open port somewhere, handle authentication (becase wherever there's an open port, there will be malicious connections), and extensive data validation (for the same reason). While these problems are applicable to dis
Then install a turnstile array half way up, hook it up to a generator, and watch it solve the world's energy problems!
I, for one, welcome our new Flash killing overlords. After all, anything that promises to kill off flash must have been made by a most honorable and considerate person, who wishes nothing more than to spare us from the many, many pains of the hostile landscape of the web.
If you actually look at the code you'll see plenty of bad coding practices. vvvv and uuuuu as variable names? malloc and free in C++ code? Cut-n-paste code where a loop ought to be? It looks like something that I might find on the "Daily WTF" site.
Here's an article detailing some other very good reasons why God can not be omnipotent, in the game or in real life:c e.htm
http://atheism.about.com/od/whatisgod/a/omnipoten
If "Pentium" is a fifth generation processor, then the next logical name should indicate a sixth generation processor. "Sexium" is just such a hot name.
... for a language that is just a hash of things created by random pounding on the keyboard.
We, C++ programmers, just got tired of being insulted all the time, so we don't talk much any more. After all, every time we mention C++ we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to writing code. If you don't want to listen, you are only hurting yourselves and your employers.
The mafia forms a political party, named "The Lovers of the Italian Opera" dedicated to legalization of loan sharking, money laundering, drug dealing, theft, and murder.
The irony here is that while it is becoming easier and easier to find stuff, every year there is less and less stuff worth finding.
And, of course, I already used it to read Slashdot. Oh, darn...
> It has no support whatsoever for colors or blinking text!
<shamelessplug>
Want colors and blinking text in your output? Use the Useful Terminal I/O Library! You get all that and the other things you have been missing since you traded DOS and conio.h for Linux.
</shamelessplug>
Get laid!
Well, as a C++ programmer, I am quite used to hearing how C++ is evil because of all the things it can do. Therefore, I am as justified as they are in saying that C++ is better than genetic code for the following reasons:
Genetic code is too low-level. While C++ comes with a standard library defining containers, iterators, and common algorithms, in genetic code you have to do everything from scratch. In quaternary. With 3D objects. Talk about a learning curve!
Genetic code has no garbage collector, and not even a simple malloc. In fact, you have to write self-modifying code to avoid memory leaks or dangling references. This makes it very difficult for the beginning programmer to write good code, and encourages bad practices.
Genetic code is not object oriented. You have to do horrible hacks to encapsulate private information or define interfaces to it. Most programmers just use a "signals-and-slots" method to pass messages, resulting in spaghetti code rivaling the worst abuses of goto.
Genetic code is too flexible. If you thought bad C++ code was hard to understand due to operator overloading, wait 'till you see the things a bad programmer can do with genetics! And, while in C++ the worst that can happen is a crash, bad genetic code could eat you.
Genetic code takes longer to develop for. You have to write lots and lots of code to duplicate even the simplest C++ line. Furthermore, compilation times totally suck, approaching twenty years for complex programs!
Genetic code has an arcane syntax, leftover from the early days of evolution. Just imagine, we're still using constructs nearly three billion years old! If you thought having some C in C++ was bad, wait 'till you see the archean leftovers you are forced to use in your eukaryotic cells!
Genetic code is dynamically typed and favors the "duck typing" philosophy. This creates an enormous amount of security holes, where special ducks ("poisons") with appropriate appearance but malicious behaviour could be introduced into the system.
Genetic code is hard to debug. Having no debugger, one has to rely on contrived printf-like trace statements. Unlike printf, the genetic equivalents are limited in number and expressiveness, sometimes making it impossible to figure out what is wrong.
Genetic code is a bloated pig. Just imagine, you need trillions of bits to define a simple organism, while in C++ I can code NPCs in under a hundred lines of code.
Genetic code VM is slow. Perhaps not as slow as Java, but it still takes milliseconds to do even simple operations. We could all think so much faster if we were written in C++.
Java applications are usually supposed to run in a VM on the user's machine, which is problematic because it requires both support for it and good security. In many places Java is locked out because people heard the VM was insecure. I have never enabled the darn thing at all and never saw any Java app I wanted badly enough. Add to that the fact that embedded Java apps don't look like HTML and they don't look like the OS, and it is a recipe for disaster.
Server-side Java VMs are probably shunned because of their memory footprint, which is too large to allow a heavy load. That leaves lighter scripting languages like Ruby, which are used mostly because there really isn't anything better.
As for C++, it is hard to do web development in it due to lack of libraries. People also have this irrational fear of the language, fueled by decades of unjustified FUD. And, C++ programmers really would rather write desktop applications, even though the current fad is against them. IMO, this web application fad will blow itself over, just like all the previous attempts to make thin clients. The approach is particularly ridiculous now that even a $300 computer is more than enough for most mundane tasks. What will come after it? We'll either fix the desktop so that people will stop trying to find "solutions" like the web application, drop into a dark age, or whatever.
I finally have an unbreakable number to use as my GPG key!
Saying "information wants to be free", even if they actually did so, would not promote music piracy. Music is not information, it is art, and art usually does not want to be free. Price reflects quality (in an ideal world, at least), and good artists are always going to be in demand, and consequently, in money.
28%? Come on! Which university did they go to? Some girls college, no doubt. In my graduating class there were two women and a about a hundred men, so that works out to two percent or so.
> the added horse pollution will give you a net loss
Of course not! You use the horse dung to power the steam engine!