Uz kā/iekš kā top Tavas piezīmes, uzmetumi u.c. tamlīdzīgs šaits, kad kaut ko pieraksti, skicē u.tml. app.development procesā?

A *good* C++ programmer will probably write code that outperforms the equivalent in Java. A *good* C+ programmer will remember to deallocate all of his objects to prevent memory leaks. A *good* C++ programmer will copy his strings correctly to prevent buffer overflow exploits.

If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by. When you add the real world to the picture you find that simple things like garbage collection and a virtual machine can make a mediocre java programmer outperform a mediocre C++ programmer.

If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.

No he won't. Because if he has to think about either of those things, he is programming C in a C++ environment. And is therefore not a *good* C++ programmer. His code is probably not even exception safe. He'd be kicked off any decent C++ programming team rather quickly. That aside, I'm reminded of a joke that does go somewhat against my point, but is still funny:

Bjarne Stroustrup : why so many people use "C++" just as "C" ?
Dennis Ritchie : because you named the language "C++", not "++C"

PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes.

No Ian Bicking bloga.

Cilvēkiem patīk atsevišķi vērojumi un atsevišķas zinātnes vai nu tāpēc, ka viņi iedomājas sevi par to autoriem jeb izgudrotājiem, vai arī tāpēc, ka viņi ieguldījuši tajās vislielākās pūles un visvairāk pieraduši pie tām. Ja šādi cilvēki nododas vispārīgiem vērojumiem un filozofijai, viņi to sagroza un izkropļo savu iepriekšējo nepamatoto izdomājumu ietekmē.

Google maksā 4500$ studentiem par sekmīgu piedalīšanos atvērtā koda projektā.

Ja esi students — piesakies!

  for xxx in xxxxxx:
    for xxxx in xxx:
      for xxxxxxxx in xxxx:
        for xxxxxx in xxxx.xxxxx:
          try:          
            if (xxxxxxxx.xx * xxxxxx).xxxx():
              return False
          except:
            continue

This error happens when a program is linked to two different threads libraries. Both use init sections to set themselves up, so when the second one gets initialized it complains with that very obscure error message.
(...)
Try running the following script:

#! /bin/sh
( find -s /usr/local/lib /usr/X11R6/lib -name "lib*.so"
 find -s /usr/local/bin /usr/X11R6/bin/
) |
xargs ldd -a 2>/dev/null |
awk '
 /^[^\t]/ { cmd=$1 }
 /^\tlibc_r.so/ { printf "%s\t%s\n",cmd,$3 }
'

That should print out all the libraries and programs that are explicitly linked to libc_r.so. Rebuild the ports they came from and you should be okay.

After more than 30 years of programming we ought to know that the design of complex software is inherently difficult. This despite of the fact that, for decades, the industry has been advertising programmers' positions by claiming that programming is easy. Later on, when doubts arose even to the advertisers, they switched to promising a wide variety of tools to facilitate the arduous tasks. Tools became the slogan; the right tools, paired with clever tricks and serious management methods, would work wonders. Then Edsger Dijkstra called Software Engineering 'Programming in spite of the fact that you can't'.

Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience, on precise, logical thinking, and on pedantic exactness. No magic will do.