• dkf (unregistered) in reply to Anonymouse
    Anonymouse:
    An experienced programmer might say "anyone who would reimplement HashTable in such a way is completely incompetent and should not be working here". And that would make him seem arrogant to a clueless manager. But it's also, objectively, the truth.
    Not quite. A really experienced programmer might well reimplement a hash table class to increase the set of Good Properties enjoyed by the implementation. Examples include defining a stable iteration order (sometimes very useful) or guaranteeing that there are no memory reallocations in use (again only sometimes useful and very difficult to get right, but sometimes vital; it matters when you've got millions of entries).

    There are many levels of programming ability. You've got some way to go, young grasshopper.

  • dkf (unregistered) in reply to Talchas
    Talchas:
    In the simple to moderate cases, this is perfectly true. In fact I expect most errors of this sort that people make are where they forget how the code flows (or just plain forget to free/delete).
    Agreed. I'm almost tempted to say that the cases when you can couple the lifetime of an entity to some piece of language scope are the "trivial" ones. (Java makes it harder than it should be, but it's still not difficult there. But many languages do a better job.)
    Talchas:
    However there are cases (especially when writing threadsafe libraries of certain types) where there is no way to know for sure if a given object is being used other than to use GC or reference counting. In those cases trying to tack on GC of some sort can be a PITA.
    Plus it's unwise to guarantee the order of deletion even with reference counting. In particular, it's important to not guarantee that the object will be immediately finalized upon its reference count going to zero. If you don't do that, you can all too easily end up blowing the system stack up when taking apart a very large recursive structure...
  • Bobble (unregistered)

    If you want to access your data by index, you should store it in an ArrayList.

    Unless you are using 1.x which doesn't have generics, your data should be stored in a generic List. It requires less memory for primitives, and is type safe.

  • anonymous (unregistered)

    this is the remove method of System.Collections.HashTable reflected ...

    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)] public virtual void Remove(object key) { uint num; uint num2; Hashtable.bucket bucket; if (key == null) { throw new ArgumentNullException("key", Environment.GetResourceString("ArgumentNull_Key")); } uint num3 = this.InitHash(key, this.buckets.Length, out num, out num2); int num4 = 0; int index = (int) (num % this.buckets.Length); Label_003A: bucket = this.buckets[index]; if (((bucket.hash_coll & 0x7fffffff) == num3) && this.KeyEquals(bucket.key, key)) { Thread.BeginCriticalRegion(); this.isWriterInProgress = true; this.buckets[index].hash_coll &= -2147483648; if (this.buckets[index].hash_coll != 0) { this.buckets[index].key = this.buckets; } else { this.buckets[index].key = null; } this.buckets[index].val = null; this.count--; this.UpdateVersion(); this.isWriterInProgress = false; Thread.EndCriticalRegion(); } else { index = (int) ((index + num2) % ((ulong) this.buckets.Length)); if ((bucket.hash_coll < 0) && (++num4 < this.buckets.Length)) { goto Label_003A; } } }

  • (cs)

    wow, just wow, i guess someone had a hangover and missed their "data structures theory" lectures. I'd be thinking about getting in some code auditors to check over some of this guys old code too.

    I know there are some instances where you implement some data structures yourself(ie. first year CS classes) but rarely

    I'm not sure how you could actually have worked as a programmer without understanding basic things like hashmaps, as well as the concern with the number of methods, i know i said it at the start but WOW.

  • (cs) in reply to David
    David:
    I don't know why people always knock Bubble Sort. It works, it's easy to code, and most of the time it's fast enough. Of course you need to understand when NOT to use bubble sort too.

    If you're going to implement your own sort, why bother with Bubble Sort when there are others that are more efficient and just easy to implement.

    What's the point? It has no advantages ... other than the fact that it's the first sorting algorithm you typically encounter in your average "how do I use this programming language" textbook.

  • Chris (unregistered) in reply to froggie
    froggie:
    David:
    I don't know why people always knock Bubble Sort. It works, it's easy to code, and most of the time it's fast enough. Of course you need to understand when NOT to use bubble sort too.

    If you're going to implement your own sort, why bother with Bubble Sort when there are others that are more efficient and just easy to implement.

    What's the point? It has no advantages ... other than the fact that it's the first sorting algorithm you typically encounter in your average "how do I use this programming language" textbook.

    OK, I'll bite.

    Which standard sorting methods are just as easy to implement as bubble sort? (You used plural)

    There are none simpler that work on unordered data.

    And when I'm prototyping an idea, I'm focused on the idea, not the elegance of that piece of it... hell, I might even inline the sorting code rather than shove it in a function... just until I can confirm that my concept works.

  • CoyneT (unregistered) in reply to QuinnFazigu
    QuinnFazigu:
    TheophileEscargot:
    I think this is a good counterexample to the people who say that CS degrees are pointless since most of the content is never used. Self-taught programmers can often have big gaps in their knowledge like this, since they've never had to learn boring stuff like data structures.

    Did the article say James was self-taught? If we're going by anecdotal evidence, every WTF I've seen perpetrated by a current employee has been from a college-educated person. The best programmers in our department are self-taught.

    It's often the case. Being a good programmer has much more to do with what might be called "motivation to learn" than it does with "formal training."

    People with the former attribute continue to learn better ways to do things, while the latter forget everything they were formally taught and just get worse and worse ...

  • CoyneT (unregistered) in reply to seaturnip
    seaturnip:
    DWalker59:
    Speaking of efficiency, the best way to sort an array is to repeatedly reorder it randomly, and then stop when one of the random reorders happens to place the array in sorted order.

    Yep, that's what I always do. Comparison sort with O(n) best-case efficiency, baby!

    I take it you're on a quantum computer. (Lucky you.) The rest of us have to live with computers where this is O((n-1)*(n!)).

  • bull (unregistered)

    Mine has only 1 function, it should be the most efficient one:

    DoIt(Action action,params arg[]) { switch(action) { } }//Action is an enum

  • (cs) in reply to Ben Blok
    Ben Blok:
    Devek:
    I don't know C#.. but one of the things that has troubled me in the past about "high" level languages(like Java) is that it requires an immense amount of knowledge to be able to do anything correctly while attracting novice programmers left and right.

    Just normal C is easier to program in because you know what your C code is doing for the most part. Novice programmers should start there.

    To write good Java code you have to not only know what your code is doing, but how everything your code is doing is implemented.

    Perfect example of novices using a "high" level language when they don't know enough about coding is Gentoo's portage system. Python is the worst offender when it comes to luring in novices to do something they have no business doing.

    I do not really agree on this mainly because C has the huuge overhead of learning memory management. C makes shooting yourself in the foot really easy.

    The problem with C is that often your foot is actually a pointer to your head.

    (note: looong time C/C++ programmer, now programming in C# ... so, no religious issues here, just the facts, ma'am)

  • Jack (unregistered) in reply to Nonymous

    Because some programmers don't understand the heap or pointers. Those people shouldn't be allowed to program in C/C++ or anything without garbage collection.

    Now, that's not the end of it. If you're programming in Jython/Ruby/PHP/Perl/Whatever and you don't understand the heap and pointers, don't understand how you're language works with pass by reference / value, function lookup etc., you're going to write a bunch of crap that will cause your employer to rue the day they hired you. So you can (barely) get away with being an idiot with the right language. With the wrong one, you're dead.

  • (cs)

    did Yakir fire him on the spot?

  • David Betz (unregistered) in reply to K

    "That's why VBScript is better"

    We will all assume you are joking.

    "...knows how costly function calls are..."

    IE6? Firefox? Opera? Safari? Compared to what? In what context? For what purpose? Intense graphics for Trident? Yes. Request queuing in Firefox? No? Statistical calculations? That should be in compiled code anyhow.

  • Remagen (unregistered) in reply to Paddington Bear

    You know, I thought you needed to get a college degree for these kind of jobs.... And I thought a college degree would preclude some complete stupidity?

  • uglyduckling (unregistered)

    uglyduckling says: "ARRRGHHHH ... Now i have seen EVERYTHING"

    puts gun to james's head bang bang

    evil smile

    puts gun to own head bang

  • (cs) in reply to TwelveBaud
    TwelveBaud:
    "Your brain has too many synapses. Mine just has three. It's more efficient."

    Fail.

    LMAO!

  • Ranulf (unregistered) in reply to CoyneT

    Meh. I've seen as many misfires from self-taught as from formally trained so I wouldn't be so categorical about it. The nature of the misfires are different though. Most self-taught misfires are due to gaping holes in their basic knowledge because they haven't been dragged through all the boring stuff. Most formally-trained misfires are due to intellectual laziness and arrogance. This WTF looks like a self-taught dud. Mind you, there's nothing stopping self-taught from being insufferably arrogant and formally trained from having gaping holes (amnesia sometimes sets in 5 seconds after final exams). This is why every job interview should involve writing (pseudo-)code. You just can't judge people on their papers.

    CAPTCHA: pirates - gallow birds the lot of them. Yarr.

  • Anonymouse (unregistered) in reply to dkf
    dkf:
    Anonymouse:
    An experienced programmer might say "anyone who would reimplement HashTable in such a way is completely incompetent and should not be working here". And that would make him seem arrogant to a clueless manager. But it's also, objectively, the truth.
    Not quite. A really experienced programmer might well reimplement a hash table class to increase the set of Good Properties enjoyed by the implementation. Examples include defining a stable iteration order (sometimes very useful) or guaranteeing that there are no memory reallocations in use (again only sometimes useful and very difficult to get right, but sometimes vital; it matters when you've got millions of entries).

    There are many levels of programming ability. You've got some way to go, young grasshopper.

    I said "in such a way", referring to James' linear key/value array. ;) Of course there are plenty of cases where you'd want to extend/replace library classes. The point was just that recognising and pointing out the extent of James' incompetence might make one seem arrogant. Which probably goes a long way towards explaining why James isn't flipping burgers for a living.

  • Anonymouse (unregistered) in reply to Chris
    Chris:
    Which standard sorting methods are just as easy to implement as bubble sort? (You used plural)

    Random sort and.. what's it called.. repeatedly searching for and extracting the element with the lowest key, and building a sorted array out of that, I think it has a name. Insert sort is also fairly simple.

    Well, actually bubblesort is simpler still. But "fast enough"? No way. For example quicksort is really simple to implement, like a slightly warped, recursive bubblesort, and my experience is it starts to outperform bubblesort at 10 or so elements. The extra overhead means nothing next to the difference in time complexity.

    1000 elements is certainly well beyond the useful scope of an O(n^2) algorithm when quicksort is so simple. Even, I would say, for prototyping purposes.

  • NiceWTF (unregistered) in reply to Devek
    Devek:
    Check the python source for it :P I'll submit a few WTFs based on it next week when I get time.

    Please do, that could be interesting :)

  • Jon A (unregistered) in reply to NiceWTF

    Must... resist... the urge... to reinvent... the wheel...

  • dkf (unregistered) in reply to Anonymouse
    Anonymouse:
    Random sort and.. what's it called.. repeatedly searching for and extracting the element with the lowest key, and building a sorted array out of that, I think it has a name. Insert sort is also fairly simple.
    You're thinking of selection sort. If you can afford the space or you're using a linked list, it's a good way to do it. There are more powerful schemes for sorting arrays (i.e. structures with O(1) access by numeric indexes) though.
    Anonymouse:
    Well, actually bubblesort is simpler still. But "fast enough"? No way. For example quicksort is really simple to implement, like a slightly warped, recursive bubblesort, and my experience is it starts to outperform bubblesort at 10 or so elements. The extra overhead means nothing next to the difference in time complexity.
    Quicksort's got some problems though; for example, it's formally O(n^2) unless you do some fancy tricks with pivot selection (which make it quite a bit more complex) and it's not stable (i.e. keys that are the same can end up in any order, which can matter a lot in practice). A better sorting algorithm is mergesort, which has a worst case only slightly slower than quicksort's best case, O(n log n), and which is stable. It's also about the same complexity to implement, and is what Java actually uses for sorting (not so sure for C# and the google-fu is not strong with me this morning).
  • Mike (unregistered) in reply to Anonymouse
    Anonymouse:
    Chris:
    Which standard sorting methods are just as easy to implement as bubble sort? (You used plural)

    Random sort and.. what's it called.. repeatedly searching for and extracting the element with the lowest key, and building a sorted array out of that, I think it has a name. Insert sort is also fairly simple.

    Well, actually bubblesort is simpler still. But "fast enough"? No way. For example quicksort is really simple to implement, like a slightly warped, recursive bubblesort, and my experience is it starts to outperform bubblesort at 10 or so elements. The extra overhead means nothing next to the difference in time complexity.

    1000 elements is certainly well beyond the useful scope of an O(n^2) algorithm when quicksort is so simple. Even, I would say, for prototyping purposes.

    The real question should be why would anyone (well, anyone using Java or C# at least, apart from as College/University exercises) actually implement any sort algorithm? The sorting algorithm used by the Java Collections class is a modified mergesort with n log(n) performance, it's stable, it's damn fast and it's been extensively tested (both by Sun and indirectly by every developer that ever used it). I can think of no good reason to implement any other sort method in Java and I would be amazed to learn that C# (and other modern languages) don't have similar standard methods for sorting. As for C and C++, well most of these algorithms have been around for about 50 years if you can't find a "standard" version I'd recommend Robert Sedgewicks Algorithms in C/Algorithms in C++.

  • (cs)

    Confession: I stand guilty of having once implemented quicksort in Javascript (copied straight out of chapter 4 of K&R, and translated from C to Javascript) because I hadn't been working with the language long enough to know it had a built-in sort. As soon as someone told me, I recanted my ways.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Oops, sorry. My Beverage-supply-solution Person is over-qualified. At least it can boil water. If it exists, which it doesn't. And I don't have one. I am therefore in possession of an imaginary tea-person who is unqualified to fulfill its role in life by writing a marginally less insane version of something that it fondly thinks is a "hash table."

    Drinking and posting again, R_A?

  • toneii (unregistered)

    So we started out to laugh as someone with weaker capabilities than us, thereby making us feel superior. However, in wading through the pages of self congratulation, I seem to see that most of us are debating extremely complicated aspects of this "simple problem"... So are we still superior or are we the dummies?

  • Anonymouse (unregistered) in reply to Mike
    Mike:
    As for C and C++, well most of these algorithms have been around for about 50 years if you can't find a "standard" version I'd recommend Robert Sedgewicks Algorithms in C/Algorithms in C++.

    Yes. Or lookup the algorithm on Wikipedia, implement it once in an open-ended way and you're done. And yes, sorting in Java and C# is as simple as using the built-in functions, unless you're doing something really special-purpose (e.g. something that calls for radix sort).

  • kblees (unregistered) in reply to Nonymous
    Nonymous:
    Devek:
    <snip/> If you can't write C without shooting yourself in the foot over and over you will not be able to write good code in any language.

    There isn't a language that has built in stupidity protection.

    Then clearly every programmer out there must be incompetent.

    I love when people start making claims like this because they're hilarious. I mean... "its not that hard to manage memory or check array bounds," but clearly... it is.

    Way too many pieces of software have buffer overflows, format string issues, memory leaks, and all kinds of other problems for C/++ to be "that easy." Apache, ruby, php, Webkit, Firefox, Internet Explorer, and everyone else. Worse, when you start corrupting memory because you didn't check bounds right there's no recovery at all. In a high level language like Java you'll get exceptions when you do something like this, and the issue can be handled gracefully... (worst case the program can save the open files and quit), without the process ending abruptly, as would be the case if you had a segfault in C.

    Seriously folks. If programming in C/++ was so easy, manual memory management was so straight forward, and checking your array bounds so simple, why are there still so many horrible security issues in programs? Why do browsers and text editors still crash?

    </rant>

    Wow! I think this comment is the real WTF of the day.

    As if Java or C# would protect you from serious bugs or security issues! This is just plain ignorance.

    I agree that array bounds checking is a Good Thing. However, when it comes to memory management, there is a simple rule that applies to all languages out there: if you allocate a resource, you have to release it some time later.

    In C++, this applies to all resources, including memory. In Java/C#, memory is handled by the garbage collector, and all other resources are simply a pain in the ass.

    Consider this C++ code: ifstream f("filename"); ...do something

    The SIMPLEST way to do this correctly in Java (without IoC tricks) is:

    InputStream s = null; try { s = new FileInputStream("filename"); ... do something } finally { if (s != null) s.close(); }

    Of course, InputStream s = new FileInputStream("..."); will also just work - for a while... (seen it so many times...sigh). And as memory is used more often than other resources (files, sockets, db connctions etc.), automatic memory management simply allows you to write much more of such broken code until you realize your stupidity.

    Seriously, if you really find the concept of releasing resources hard to grasp, you should probably look for a 'flipping burger' job, will save you (and your colleagues) some frustration...

  • Andrew (unregistered)

    I once worked with a .Not programmer who wrote the following for his sleep function (I don't know VB so I'm writing it in Java):

    public sleep(long milliSeconds) { long target = System.currentTimeMillis() + milliSeconds; while (System.currentTimeMillis() < target) { ; } }

    And for some reason the process he would be waiting on to complete would rarely get done.

    His qualifications: Well, I worked a lot with spreadsheets and decided to get into VB programming.

    Unfortunately hiring managers (and recruiters) are happier at alphabet soup on resumes than anything else.

    I had a few recruiters actually ask me "What is J2EE anyway?" after placing me. Of course this was back in the day where J2EE was just out but they wanted 5 years expierence.

  • dkf (unregistered) in reply to kblees
    kblees:
    The SIMPLEST way to do this correctly in Java (without IoC tricks) is:

    InputStream s = null; try { s = new FileInputStream("filename"); ... do something } finally { if (s != null) s.close(); }

    Actually, you get just as good results from this:

      InputStream s = new FileInputStream("filename");
      try {
         ... do something
      } finally {
         s.close();
      }

    If it's not obvious why this simplification works, think about conditions under which you'll be able to close the stream in the code. (Also note that you [i]can't[i] trivially combine this with catching a failure to open the stream; that requires another try round the outside...)

  • Andrew (unregistered) in reply to dkf
    dkf:
    kblees:
    The SIMPLEST way to do this correctly in Java (without IoC tricks) is:

    InputStream s = null; try { s = new FileInputStream("filename"); ... do something } finally { if (s != null) s.close(); }

    Actually, you get just as good results from this:

      InputStream s = new FileInputStream("filename");
      try {
         ... do something
      } finally {
         s.close();
      }

    If it's not obvious why this simplification works, think about conditions under which you'll be able to close the stream in the code. (Also note that you can't trivially combine this with catching a failure to open the stream; that requires another try round the outside...)

    So there do you catch the exceptions FileInputStream("filename") can throw? This may be simple but it doesn't compile.

  • (cs) in reply to Andrew
    Andrew:
    dkf:
    kblees:
    The SIMPLEST way to do this correctly in Java (without IoC tricks) is:

    InputStream s = null; try { s = new FileInputStream("filename"); ... do something } finally { if (s != null) s.close(); }

    Actually, you get just as good results from this:

      InputStream s = new FileInputStream("filename");
      try {
         ... do something
      } finally {
         s.close();
      }

    If it's not obvious why this simplification works, think about conditions under which you'll be able to close the stream in the code. (Also note that you can't trivially combine this with catching a failure to open the stream; that requires another try round the outside...)

    So there do you catch the exceptions FileInputStream("filename") can throw? This may be simple but it doesn't compile.

    Haven't gone near Java for 7 years now, but should compile?

    Side point, i like the C# way..

    using (FileStream fs = new FileStream(..))
    {
        // do something..
    }
    

    quite elegant, though if you wanted to catch Exceptions you would

    try
    {
       using (FileStream fs = new FileStream(..))
       {
    
           // do something..
       }
    }
    catch (SomeExceptionType e)
    {
       // do something...
    }
    
    
  • Bei (unregistered) in reply to jpaull
    jpaull:
    I think every seasoned programmer has experienced a junior developer with some bizarre misconceptions about basic concepts (My personal favorite is "The only difference between inner joins and outer joins is that inner joins are faster").

    The ones [programmers] that turn into good developers are the ones that are open-minded and willing to learn.


    INTRO -- arrogance and the ego

    Being able to express open-mindedness and willingness to learn is hard when one receives an upper-level degree in Computer Science with honors and high GPA or spends tons of time to self-learn programming languages that creates a self-persuaded large ego that makes it natural to act arrogant (i.e., that they know more than everyone else). The trick is to deceive others around you that you're a novice, because the ego (i.e., selfishness that one is correct [and right] because of the time put into self-learning or the degree or both) wants you to keep the ego well-fed, which means remaining to feel superior over others. One can prevent the ego-emotions of feeling superior similar to one can prevent the hatred emotions that come when someone you feel has offended you.


    ACT THE WAY OTHERS ACT -- silences the ego's emotional struggle (because you don't have to defend anything)

    Ego is the inevitable curse to a person that has been proven by "society" (either high grades, SAT scores, hanging out with people that fully accept their ideas, or self-learning for a very long time) to be right and superior over others and the fact that being wrong makes you look stupid, powerless, and worthless. Saying that someone is wrong is basically saying that "my ideas are superior to yours". This persuasion is an argument that is being played out in every single conversation that you will endure. If [ your ego is crossed (e.g., if I were a slave owner, and somebody said that what I was doing is wrong) ] ; I'm going to feel inferior against the somebody that disagrees with me ("how dare they make me feel like I'm not doing 'right' and attempt to make me turn against myself"), especially if that somebody has no good support to suggest that I'm wrong with having slaves. I would feel that the only reason the person objects my slavery acts is to slap me in the face and say "My ideas are superior to yours". That's why if you spread ideas, do not spread ideas that the other person doesn't know or won't understand or is against their core beliefs, because they'll be convinced that they're ignorant and inferior; they'll resent you. Be safe. Act the way others act, and do what others do -- spreading information that makes you look "special" and more intelligent than everyone else will make others resent you for making them feel like they're wrong/stupid/ignorant (which multiplies if you make yourself look special with others around you), which in turn makes them feel powerless. Feeling powerless leads to resentment (secretive anger), and the person will blame you for how they feel about themselves (i.e., powerless). On the other hand, if you make someone feel powerful, they'll want you to stick around, and will reward you in any ways that they can (which is what you want, because you're steering them directly into your intentions). Their control over you becomes your control over them, which is a mutual relationship. You can deceive that you're helping them, but of course that depends on the situation.


    DAMPENING EMOTIONAL RESPONSES THAT HURT CONTROL

    To prevent being angry when being offended is to realize you're 100% responsible for being angry and what you think, and that arguments created by others are owned by them, and have nothing to do with you. You always have the choice to not be apart of their "game". Since you know the other person wants to start an argument and be "right", just agree with them, because control over them is more important than feeding an ego that is never fully quenched. Agreeing with somebody that you'd really like to disagree with is a great way to test yourself on how deceitful you can actually be. The more skilled you are at using deceit, the more easier it is to control others, because you aren't continually trying to feed your ego, you're trying to remain in the control seat. Remember, if they're convinced they're right, and if you were them, you'd be convinced too. It's a good technique to prevent your ego from persuading you that you should attack (either by the excuse of annoyance or being pushed around).


    EXAMPLE OF SUPREME CONTROL -- babies

    The argument everyone has about themselves is that they have to feel right/superior, which is an argument that everyone has within themselves. People that pretend to not be superior and therefore innocent (e.g., babies and kids) are the most powerful of all. They make you look superior and responsible, and they use that to their advantage to get what they want. "You should change my diaper because I can't do it, you'd hurt your ego of being a responsible parent if you didn't (and therefore how you think society looks at you is poor), and Mom is going to be pissed at your irresponsible actions". This feeling of "I need help because I can't do it and so therefore you should do it" is used a lot with females to get males to protect them, to give them money, and fix their cars. The problem with this scenario is that females will be labeled as "weaklings", which is used as a control-mechanism for the females to protect their intentions of wanting to be "lazy". We feel morally responsible to help, because if we don't, then we don't get our intentions fulfilled, reproduction, and our other intentions, like the need of fulfilling what the society thinks is "good" -- which comes with threats like jail time and people around you feeling inferior towards you.

    But do babies need to feel superior? By pretending they are weak they get the control over the parents, and therefore they're practically superior.


    ACT THE WAY OTHERS ACT 2 -- "society"

    To prevent the ego wanting you to feel right/superior/correct over others (and therefore look at you with inferiority and resentment) is to consciously act the way they do. Nothing makes a person feel better and more accepted when you follow the rules that make a person "good" for the target person you want to control and use:

    • respectful (e.g., flattering superiors with questions that make you look incompetent, which in turn will make them look superior)
    • responsible (the resume gives a lot of this)
    • trustworthy (are your intentions known and "good") Never ever give emotions that say "I think you're wrong", because that lowers their ego, it makes them disappointed in themselves, and they'll see you as the reason to why they're "inferior" to society. The people that they know, creates "society" for them. I know I don't know all 300 million Americans, but the 10 people around me that I know and the media seem to give me a clear picture of what "society" likes and dislikes. Society "goods" would be things like: being employed, responsibility, trust, equal benefits for everyone, peace, anti-terrorism, following the laws, going to school, getting good grades, not being in-debt, getting around with the opposite sex, etc. etc. Human properties like responsibility and trust are shrouding the true intentions of those properties. Responsibility and trust are actually saying "how much control do I have over this person to do what I ask?". The society "goods" like responsibility and trust are ways of making you look like your intentions are for the good of society, but you can use the society "goods" as a way to fog your true intentions (e.g., winning the bosses favor to get promotion, or getting an instructor's trust to get an excellent scholarship recommendation, or whatever you want depending on how clever you are) with so-called "higher morales" (i.e., the list of social "goods").

    IDEAS ARE PERSUASIVE -- so use with care.

    Aristotle said that ALL ideas are persuasive. If I said that 2=1, I'd bet you would be partially persuaded that 2 does equal 1, because deep inside you know that there is a probability that I'm right, therefore nobody could prove that I'm wrong. And since I didn't give any support, how could somebody counter-argue? Since I said 2=1, and you know that "society" would know that I'm wrong, you see me as inferior, because you see me as trying to be superior over others because I think I know more than everyone else. So even if I did know 2=1, or that Christianity is false or true, I would KEEP THAT TO MYSELF, because if everyone thinks I'm inferior, how am I suppose to get a pay raise? or a promotion? or fulfill my intentions? That's where deceit comes in. You keep your real ideas to yourself, and consciously play a power game. You play as the innocent, friendly, high-moral character, that makes others feel accepted into society, so that when it comes time for the boss to give a raise, the boss will choose the person that makes him/her feel less inferior (i.e., more in power, more in control, more RIGHT).


    CONCLUSION -- back to jpaull

    So back to the beginning. jpaull stated, "The ones [programmers] that turn into good developers are the ones that are open-minded and willing to learn." My response? It's the programmers that look open-minded and willing to learn. An employer can be deceived (e.g., with fake intentions that look real enough [e.g., to further pursue a career and my personal growth]) and therefore controlled to get what you want, which is the job. What you need to know is what you want, and how you can do get what you want cleverly, while using the potent weapon of deceit to your advantage.

  • JSmith (unregistered) in reply to Fiona

    They ask for 20K less than we do. Then you get the brilliant employers who think that the supposed cost savings is worth it and well written code is overrated and unnecessary.

  • Jon (unregistered)

    I would gladly take James' place at that company. I know C# and apparently James does not. :P All I can say is "wow ...". My head hurts after trying to process his logic.

  • Stu (unregistered) in reply to VGR

    Boohoo in j2me world we still have to live with them, I remember the days of Collections, Autoboxing, Generics... but have to stick with Vectors and Enmerations and casting...

    No enumeration for me... also, lots of people in my j2me team have never used Generics as they used j2se before it had them.

    Captcha: gotcha

  • (cs) in reply to Mike
    Mike:
    Anonymouse:
    Chris:
    Which standard sorting methods are just as easy to implement as bubble sort? (You used plural)

    Random sort and.. what's it called.. repeatedly searching for and extracting the element with the lowest key, and building a sorted array out of that, I think it has a name. Insert sort is also fairly simple.

    Well, actually bubblesort is simpler still. But "fast enough"? No way. For example quicksort is really simple to implement, like a slightly warped, recursive bubblesort, and my experience is it starts to outperform bubblesort at 10 or so elements. The extra overhead means nothing next to the difference in time complexity.

    1000 elements is certainly well beyond the useful scope of an O(n^2) algorithm when quicksort is so simple. Even, I would say, for prototyping purposes.

    The real question should be why would anyone (well, anyone using Java or C# at least, apart from as College/University exercises) actually implement any sort algorithm?

    That's my thought. If you're prototyping, use the built-in sort. If you have to write your own, then you should have have one in your personal "library" that you can just call. In which case the complexity of merge-sort (or whatever) is packaged in an external function/method/class (depending on language).

    Course I don't always do what I "should" do either ...

  • Mr Fred (unregistered) in reply to Paddington Bear
    Paddington Bear:
    I find my car has a radio, cd player and air conditioning, so it's much slower.

    Walking is a much simpler operation and much more efficient.

    Can you help me walk at 70mph please?

    Here is a case where the radio and A/C do slow the car down:

    http://www.seriouswheels.com/cars/top-2004-Caterham-Superlight-R500-Evolution.htm

    0-100-0 in 10.73 seconds.

  • flukus (unregistered)

    Reminds me of a University Educated guy I work with a while ago that used arrays instead of lists because they were faster. Never dawned on him that array resizing took so long. He also like to create his own specific bubble sort for each function.

  • Paleogeek (unregistered)

    Reminds me of something that happened on my 1st job after grad school (many, many years ago). I wanted to hang around the college since my wife was still working on her PhD and the only job I could get was in a gov't lab doing fortran & cobol. My boss hired a guy because he was down on his luck and went to his church. One of the first tasks we gave him involved reading a file from a tape. His program ran for hours on a small test tape before we killed the job. Upon examination he was opening and closing the tape before/after each read - open, find start of records, read one record, close, rewind tape, repeat...
    One moral of this story - before you crab about civil servants, remember that you get the servants that you're willing to pay for.

  • kblees (unregistered) in reply to dkf
    dkf:
    If it's not obvious why this simplification works, think about conditions under which you'll be able to close the stream in the code. (Also note that you can't trivially combine this with catching a failure to open the stream; that requires another try round the outside...)
    Yeah, thanks for straightening me out - that's what happens when you remove exception handling for simplicity.

    However, with proper exception handling, your nested try catch approach is not really a simplification (in fact, when adding another stream its more complex). And putting cleanup code within another try block poses its own problems. Consider this:

    try {
      InputStream is = new FileInputStream("in");
      try {
        OutputStream os = new FileOutputStream("out");
        try {
          // ...do something
        } finally {
          // will compile fine, but exception in os.close() will
          // hide whatever went wrong in the try block
          os.close();
        }
      } finally {
        is.close();
      }
    } catch (IOException ex) {
      // ...handle errors
    }
    

    versus

    InputStream is = null;
    OutputStream os = null;
    try {
      is = new FileInputStream("in");
      os = new FileOutputStream("out");
      // ...do something
    } catch (IOException ex) {
      // ...handle errors
    } finally {
      // is.close() won't compile here, need to handle
      // exceptions in cleanup code gracefully
      IOUtils.closeQuietly(is);
      IOUtils.closeQuietly(os);
    }
    
  • iMalc (unregistered)

    FYI: The simplest implementations of BubbleSort and InsertionSort for an array are about the same length, but InsertionSort for a linked-list is definitely shorter.

    This article is the most WTF-like I've seen in a while!

  • rawr (unregistered) in reply to Devek
    Devek:
    Ben Blok:
    I do not really agree on this mainly because C has the huuge overhead of learning memory management. C makes shooting yourself in the foot really easy.
    If you can't write C without shooting yourself in the foot over and over you will not be able to write good code in any language.

    There isn't a language that has built in stupidity protection.

    http://en.wikipedia.org/wiki/Malbolge That one has. Most esoteric languages has tbh. ;) Idiots cant even figure out how to make it work. ;) Otoh, to use such languages in real systems would be idiotic to say the least.

  • rawr (unregistered) in reply to Nonymous
    Nonymous:
    Devek:
    Ben Blok:
    I do not really agree on this mainly because C has the huuge overhead of learning memory management. C makes shooting yourself in the foot really easy.
    If you can't write C without shooting yourself in the foot over and over you will not be able to write good code in any language.

    There isn't a language that has built in stupidity protection.

    Then clearly every programmer out there must be incompetent.

    I love when people start making claims like this because they're hilarious. I mean... "its not that hard to manage memory or check array bounds," but clearly... it is.

    Way too many pieces of software have buffer overflows, format string issues, memory leaks, and all kinds of other problems for C/++ to be "that easy." Apache, ruby, php, Webkit, Firefox, Internet Explorer, and everyone else. Worse, when you start corrupting memory because you didn't check bounds right there's no recovery at all. In a high level language like Java you'll get exceptions when you do something like this, and the issue can be handled gracefully... (worst case the program can save the open files and quit), without the process ending abruptly, as would be the case if you had a segfault in C.

    Seriously folks. If programming in C/++ was so easy, manual memory management was so straight forward, and checking your array bounds so simple, why are there still so many horrible security issues in programs? Why do browsers and text editors still crash?

    </rant>

    Basically because it wasnt done right. ITs not hard to do it right,its just that every human I know of has lapses in efficiency, be it due to illness or lack of sleep, but whatever the reason, writing code in such a state will render crappy and unstable code. Which is why programmers really shouldnt be put on monster overtime and all kinds of such crap, because all you get for it is crappy code. Also, it only takes ONE poor developer (be it temporarily or permanent) to break an app of several hundreds of thousands lines of code.

  • foo (unregistered) in reply to Ch0

    That's right kids, if your employer hires nothing but idiots and you are hired there then that makes you and idiot to stay.

  • Anton (unregistered)

    Rwy nimagu, zachet! ))))))

  • (cs) in reply to CoyneT
    CoyneT:
    seaturnip:
    DWalker59:
    Speaking of efficiency, the best way to sort an array is to repeatedly reorder it randomly, and then stop when one of the random reorders happens to place the array in sorted order.

    Yep, that's what I always do. Comparison sort with O(n) best-case efficiency, baby!

    I take it you're on a quantum computer. (Lucky you.) The rest of us have to live with computers where this is O((n-1)*(n!)).

    I take it you missed the "best-case" part. If the array is already sorted, this algorithm will run in O(n) time (i.e., the time it takes to check whether the array is sorted) even without bringing quantum effects into the discussion.

  • Paul (unregistered) in reply to Fuji

    Better yet, don't implement sort at all. Use the builtin one :-)

  • AdT (unregistered) in reply to Anon

    Incorrect. What you actually want to do is sit on your behind and implement the synchronization at a higher level. This was already mentioned but I'll provide some examples just to prove the point. If you don't want to litter your entire code with synchronized blocks, make a higher-level wrapper that abstracts all operations that you need to be atomic (e.g. make a class ThreadSafeQueue or ThreadSafeStack). Actually, chances are that someone else already implemented a class that, unlike java.util.Vector, actually gives you the synchronization granularity you need. Now for the examples:

    // Example (1): Get first element, if any.
    Object first = vec.isEmpty() ? null : vec.firstElement();
    
    // Example (2): Pop element off the back of the Vector
    Object popped = vec.remove(vec.size() - 1);
    
    // Example (3): Replace a given element
    int oldIndex = vec.indexOf(oldElement);
    if (oldIndex != -1)
    	vec.set(oldIndex, newElement);
    

    (Don't even get me started on iterating through the vector.)

    None of the above examples is safe to use with java.util.Vector unless you add your own synchronized blocks. But if you need external synchronization anyway even for simple operations like these, and the internal synchronization will just add unnecessary overhead, why would you ever want to use it in the first place? Even if, as you say, the performance difference is small nowadays, the synchronization built into Vector and Hashtable will give n00bs a false sense of security.

    "Your queue code has a race condition." n00b: "No way, I'm using java.util.Vector."

Leave a comment on “It Had Too Many Functions”

Log In or post as a guest

Replying to comment #:

« Return to Article