• K (unregistered) in reply to Grovesy

    So this is a Zen programming contest?

  • Buster (unregistered) in reply to Devek
    Devek:
    There isn't a language that has built in stupidity protection.
    PHP comes close...one day I expect to see it produce this:

    Fatal error: Found 'function foo($bar)', expecting 'function processUserInput($input, $filters, $validators)' on line 41 character 3 of /home/foo/html/foo.php

  • Anon (unregistered) in reply to Jackal von ÖRF
    Jackal von ÖRF:
    raveman:
    he should use HashMap, Hashtable is slower because its synchronized :P

    just messing with you

    At least in Java. The real WTF is that people still use and teach the use of java.util.Hashtable and java.util.Vector (or even worse, java.util.Stack) instead of the newer alternatives and interfaces. It would be better for Sun to deprecate those classes.
    Why? Hashtable and Vector are the classes you want when you need synchronized access to them for access to multiple threads.

    Even better, in recent JVMs, the performance loss due to using synchronized methods is far below what it used to be. You no longer gain anything from using an ArrayList over a Vector. Try it.

  • foobar (unregistered) in reply to Ben Blok
    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.

    Replace Array.Resize() above with realloc(), and you're about 75% of the way there to having the same code implemented with gasp memory management. That doesn't make the, ehem, "HashTable" any better, but that's about as hard as memory management gets.

  • (cs) 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.

    The article said nothing of James's method of learning, personally myself, I taught myself how to program before going to college.... way before, started learning Basic at 13... pascal at 14 or was it 15... ok easy languages to start with but meh >.>... learned other languages since... unforantly OOP is still an area I have not fully broken in to yet, done some Delphi, little bit of Java hear and there... wanna get into C++... but anyway to my point!

    When I did go to college, I remember always being the go to guy for everyone else for near enough any programming activity or assignment out there, before even the lecturer's, never understood why that was, I mean I knew how to program but some of the lecturer's knew way more then I did, after all I had not been out in the industry. But never the less, some of the stuff people did when I looked at their work (as I'd finish most things in about 5 minutes when it came to programming and get high high marks for the programming, freak all for the write-up ahem, you'd be shocked how much people re-invent the wheel or miss out all too common methods of just doing things in a standardised way through out their program... it just seems for someone to learn programming, the best way is to just go out their and learn it for themself, rather then just try to do it off of what they heard in the lecturer... because that's just never enough =P.

  • krupa (unregistered) in reply to Devek
    Devek:
    If you don't know how the classes involved are implemented, you won't know why the code went from running 1,000 scripts a second to 100,000 a second on my core 2 desktop. :P If all you knew was Java and knew nothing about how it and its classes worked you would swear the previous implementation would of been faster.
    You're not convincing me. I would have implemented the same solution. Doing that may require reading source (I'm not familiar with Jython so I won't say definitively either way) but I don't need to read source code to know that repeated process creation is slower than running threads.

    Having said that, being familiar with the source code of ANY 3rd-party library for ANY language you're working with is definitely a plus. But I still disagree with the assertion that you can't write good Java unless you know the source.

  • (cs) 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.

    Hmmmm... perhaps all well written software could have some sort of "stupidity protection" label, similar to "Windows-Certified" !?

  • (cs) in reply to Grovesy
    Grovesy:
    anti-cynic:
    Better yet, screw functions:

    { }

    Screw code!, machine code all the way baby...

    Pfft! Machine code's for noobs. I feed instructions directly into the processor with a straight key. Old school baby.

  • (cs) in reply to Anon
    Anon:
    Why? Hashtable and Vector are the classes you want when you need synchronized access to them for access to multiple threads.
    No, there's still no reason to use the legacy classes. You can create synchronized versions of any Collection using the Collections.synchronizedXXX() method. http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html
  • Jezza (unregistered) in reply to Paddington Bear

    Air-con DOES slow cars down

  • Anonymous (unregistered) in reply to K

    This is the only code you'll ever need:

    Blitz!

  • (cs) in reply to foobar
    Replace Array.Resize() above with realloc(), and you're about 75% of the way there to having the same code implemented with *gasp* memory management. That doesn't make the, ehem, "HashTable" any better, but that's about as hard as memory management gets.

    The hard part of memory management in C/C++ isn't when you call malloc/realloc/calloc/new, but when you call free/delete. Especially when you have multiple threads.

  • dkf (unregistered) in reply to Anon
    Anon:
    Jackal von ÖRF:
    It would be better for Sun to deprecate those classes.
    Why? Hashtable and Vector are the classes you want when you need synchronized access to them for access to multiple threads.

    Even better, in recent JVMs, the performance loss due to using synchronized methods is far below what it used to be. You no longer gain anything from using an ArrayList over a Vector.

    The real problem with those approaches (and also the Collections.synchronized...() stuff that replaces it) is that too many programmers think that using that sort of thing makes their code automatically thread-safe. Alas, that's not so! Thinking about what the correct boundaries for critical sections, that's what you really need. (Sometimes they correlate with method calls, but not always, and it's less likely with a low-level collection than with a higher-level API.)

    There is no substitute for thinking about things. There is no substitute for knowing what you're doing.

  • SomeCoder (unregistered) in reply to krupa
    krupa:
    Devek:
    If you don't know how the classes involved are implemented, you won't know why the code went from running 1,000 scripts a second to 100,000 a second on my core 2 desktop. :P If all you knew was Java and knew nothing about how it and its classes worked you would swear the previous implementation would of been faster.
    You're not convincing me. I would have implemented the same solution. Doing that may require reading source (I'm not familiar with Jython so I won't say definitively either way) but I don't need to read source code to know that repeated process creation is slower than running threads.

    Having said that, being familiar with the source code of ANY 3rd-party library for ANY language you're working with is definitely a plus. But I still disagree with the assertion that you can't write good Java unless you know the source.

    It's not that you have to know the exact source code of Java or should review it daily. But you should know how Java works in general. If you don't, you really have no business trying to write anything more complicated than Hello World.

    Having a rough knowledge of how a language works under the covers makes you a far better programmer in the end, especially when writing code that needs to be highly efficient.

  • (cs) in reply to foobar
    foobar:
    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.

    Replace Array.Resize() above with realloc(), and you're about 75% of the way there to having the same code implemented with gasp memory management. That doesn't make the, ehem, "HashTable" any better, but that's about as hard as memory management gets.

    I am of the opinion that every programmer should understand memory management, whether or not they're using a garbage-collected language. It's a useful piece of knowledge, and it makes people more careful about allocating memory, even in Java or C#.

    Java- and C#-only people tend to have the mentality of "I'll just make a new object" whenever their fingers itch... instead of perhaps finding other ways to implement whatever algorithm they're using. I know I am guilty of doing that in C# (though I'm a die-hard C++ programmer), but simply out of laziness (WHICH IS ALSO BAD) though it was just a school assignment.

  • Devek (unregistered) in reply to krupa
    krupa:
    but I don't need to read source code to know that repeated process creation is slower than running threads.
    Jython's exec() doesn't create a process. Jython is python implemented 100% in Java. In theory doing a exec() on a already created interpreter simply passes that code off to a function which runs it. There are no threads or processes created when you execute Jython code.

    You would have to know what Jython was actually doing in Java and you would have to know how Java implemented class loaders to know WHY it was slow.

  • (cs) in reply to Devek
    Devek:
    krupa:
    Devek:
    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.
    How do you figure that? The whole point of OOP is that you don't need to know or care how a class is implemented.

    At the end of the day.. your code is going to do things like access disk and memory which are resources that are more precious than cpu cycles on modern hardware.

    I was reviewing some code for an unnamed company that was writing a server in Java for their game. They wanted to be able to update parts of the logic quickly and on the fly so they decided to use Jython which was fine and all but it was SLOW. The threads would call Jython and tell it to run a script with certain parameters. They even tried a test where they just did basic exec() calls on Jython that did nothing but return and the speed was the same so it wasn't the scripts causing the slow down.

    To fix the speed problem I simply created worker threads that were implemented in Jython that looked into a queue to grab work to do. Even though it was much more complicated, had more threads, and had more code at the end, it was 1000x faster.

    If you don't know how the classes involved are implemented, you won't know why the code went from running 1,000 scripts a second to 100,000 a second on my core 2 desktop. :P If all you knew was Java and knew nothing about how it and its classes worked you would swear the previous implementation would of been faster.

    If an API is well-written, it will provide performance guarantees; that is, O-notation statements of CPU and memory usage, as well as information about any other expensive operations it might do (such as disk I/O). Again, provided an OO abstraction is well-designed and well-documented, you shouldn't need to learn about any of its implementation details, let alone all of them.

    In real life, many/most APIs are not so well-designed, and the abstractions will be "leaky", that is, some undocumented implementation details will become relevant. An obvious case of this would be a bug. In that case, it becomes necessary to delve deeper into the components you're making use of. But even then, you hardly need to know "everything" about them, only the parts that are leaking. If that was the case, programming would be so complex and require so much knowledge that coding the simplest application would be unmanageable. (Do I need to know all the inner workings of my operating system and CPU instruction set to write a "hello world" program?)

  • iWantToKeepAnon (unregistered) in reply to hunter9000

    Phhhftt. Old school?? Hardly ...

    Who needs a processor? Just write the data on 3x5 cards and sort by hand. Now THATS old school. :-)

  • (cs) in reply to jpaull
    jpaull:

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

    AMEN TO THAT! We have hired both 'experienced' developers and some entry level people lately. The 'experienced' developers give us the most trouble. They are so close-minded to new things and think they are 'experts' at what they do know.

    We have decided to hire entry level people that we deem as 'moldable' from now on. The ones we hire realize they don't know everything and are very open to learning. We still will hire experienced developers, but only as contract positions.

    We too, like the entry level people, realize that we don't know everything and are constantly researching ways to improve our code. Fortunately we work in an environment where management is open to new ideas too.

  • burned (unregistered) in reply to Devek
    Devek:
    If you don't know how the classes involved are implemented, you won't know why the code went from running 1,000 scripts a second to 100,000 a second on my core 2 desktop. :P If all you knew was Java and knew nothing about how it and its classes worked you would swear the previous implementation would of been faster.
    This is a very specific case involving none-core components.

    None-core components that seam to be calling a Runtime.exec.

    In this case then the implementation details are required. But I don't give a flying poop how Commons Net implements FTP. Or how the Oracle drivers work.

  • tesla (unregistered) in reply to Anon
    Anon:
    Jackal von ÖRF:
    raveman:
    he should use HashMap, Hashtable is slower because its synchronized :P

    just messing with you

    At least in Java. The real WTF is that people still use and teach the use of java.util.Hashtable and java.util.Vector (or even worse, java.util.Stack) instead of the newer alternatives and interfaces. It would be better for Sun to deprecate those classes.
    Why? Hashtable and Vector are the classes you want when you need synchronized access to them for access to multiple threads.

    BEEP wrong. Please try again. This time check the synchronized* methods in Collections.

  • (cs) in reply to Ch0
    Ch0:
    Fiona:
    How... did... my god.. I don't understand what these people do to be landed in these jobs.

    That's the thing.

    How can an idiot get a job when I can't? Who do they apply to?

    But then, would I really want to work for the sort of person who'd happily employ an idiot alongside me?

    Because idiot managers hire idiot employees in order to make themselves feel better.

  • jimjim (unregistered) in reply to Devek
    Devek:
    You would have to know what Jython was actually doing in Java and you would have to know how Java implemented class loaders to know WHY it was slow.

    Sounds very interresting...

    But in the real world, processes have shit loads of handles allocated memory and threads while threads have just one execution

  • Nonymous (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.

    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>
  • Asd (unregistered)
    BEEP wrong. Please try again. This time check the synchronized* methods in Collections.

    BEEP wrong :P

    util concurrent FTW. Leaving aside the fact the a synchronized collection is rarely what you want - the synchronization is probably needed on whatever class uses the collection.

  • (cs) in reply to Nonymous
    Nonymous:
    Then clearly every programmer out there must be incompetent.

    Quite a lot of them are.

    Personally, I don't think memory management in C or C++ is especially -- and "especially" is the key word here -- difficult, and memory management in C++ is a breeze. But even otherwise good programmers report that automatic memory management improves their productivity. So nu, maybe it's difficult.

    I'm sad, though, that the designers sacrificed rigorous destructor semantics in C# to facilitate automatic memory management. There's a lot of other stuff, not just memory management, that I like to do in destructors.

  • Reaver (unregistered) in reply to Talchas
    Talchas:
    Replace Array.Resize() above with realloc(), and you're about 75% of the way there to having the same code implemented with *gasp* memory management. That doesn't make the, ehem, "HashTable" any better, but that's about as hard as memory management gets.

    The hard part of memory management in C/C++ isn't when you call malloc/realloc/calloc/new, but when you call free/delete. Especially when you have multiple threads.

    Absolutely correct!

    Cheers!

  • TheRabbi (unregistered)

    Did anyone notice that this actually has 5 functions, not 3?

  • (cs)

    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.

  • (cs) in reply to DWalker59
    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!

  • Anonymouse (unregistered) in reply to Heron
    Heron:
    I am of the opinion that every programmer should understand memory management, whether or not they're using a garbage-collected language. It's a useful piece of knowledge, and it makes people more careful about allocating memory, even in Java or C#.

    I would prefer to call it critical knowledge. As this article demonstrates, a failure to understand how Java's arrays work at the low level can lead to bad, bad places.

  • Patrick (unregistered) in reply to krupa
    krupa:
    Devek:
    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.
    How do you figure that? The whole point of OOP is that you don't need to know or care how a class is implemented.

    You need to have a clue, not necessarily know it with any great detail.

  • (cs) in reply to iWantToKeepAnon
    iWantToKeepAnon:
    Phhhftt. Old school?? Hardly ...

    Who needs a processor? Just write the data on 3x5 cards and sort by hand. Now THATS old school. :-)

    That ain't old school, that's Agile. Processor? YAGNI!

    3x5 cards? Phhhftt! Everybody knows that all you need for a Turing-complete machine is an infinitely long strip of paper, a pencil, and an eraser.

    Now, off to write me a hash table implementation. Where did I put the pencil and the eraser?

  • Shinobu (unregistered) in reply to Nonymous

    Amen. The bugs you mention may be considered easy to avoid, but apparently it is too easy to make a tiny mistake that screws things up. I think were dealing with the fact that humans generally can't deliver perfect work 100% of the time here, regardless of intelligence. Lots of these small errors will cause the program not to compile or to fail in an obvious way, but memory managent is both one of the things you have to do most and one of the things that tends to cause bugs that remain invisible for very long. And the thing is, all these bugs are machine-preventable. Yes, checking array bounds, not using deallocated memory, forgetting to free memory... all these bugs can be compeletely avoided by a good language design. So why ask progammers for the impossible? Why torment them with something like that? It reminds me a bit like primary school, where we all had to do tons of 6-digit multiplication exercises even though everyone in class new that in the real world everyone uses calculators and computers.

  • (cs)

    It's like painting 300 on the spedometer and expecting the car to go faster...

    Next he'll be painting tunnels on the sides of mountains to speed up his commute, coyote style...

  • (cs) in reply to Jackal von ÖRF
    Jackal von ÖRF:
    At least in Java. The real WTF is that people still use and teach the use of java.util.Hashtable and java.util.Vector (or even worse, java.util.Stack) instead of the newer alternatives and interfaces. It would be better for Sun to deprecate those classes.
    I think everyone agrees with you, but there are some reasons to keep them around. Here's what Sun had to say about it.

    The benefit of deprecating those classes is minor, while the cost is major: it would require a lot of people to rewrite a lot of old code, and many Java APIs would need to have methods added which use List/Map/Iterator. Java's commitment to backward compatibility is some of the strongest in existence, in my opinion, so while Vector and its brethren are annoying, I respect Sun's motivation for keeping them.

    It's a huge WTF that there still new books being written that use Vector, Hashtable and Enumeration in their code examples. That's probably a major reason those classes continue to see use, as there are certain programmers out there who are quite happy to copy book examples directly out of books into production code.

  • krupa (unregistered) in reply to SomeCoder
    SomeCoder:
    It's not that you have to know the exact source code of Java or should review it daily. But you should know how Java works in general. If you don't, you really have no business trying to write anything more complicated than Hello World.

    Having a rough knowledge of how a language works under the covers makes you a far better programmer in the end, especially when writing code that needs to be highly efficient.

    I totally agree with this and have not been trying to argument against it. Having seen some of Devek's other comments, I see what he's trying to say and I really have no argument with it at this point.

  • Wade Williams (unregistered) in reply to Fiona
    Fiona:
    How... did... my god.. I don't understand what these people do to be landed in these jobs.

    Work for an outsourcing development company?

  • Mike (unregistered) in reply to hunter9000

    They're not really legacy classes, although you can consider them to be legacy there's nothing in the docs to indicate that they are. Using them is just a (slightly) simpler option than the using the synchronised methods.

    In the version of Java I'm currently using (JDK1.5.0) the implementations of Vector and ArrayList are pretty much identical, apart for the fact that methods in Vector are synchronised, obviously (check the src.zip wherever your JDK is installed). The synchronised methods in Collections just wrap the list of your choice with a new, thin Collection that synchronises access to your original list, if anything the extra method call that this introduces would cause it to be slightly less efficient (although that performance hit would be so incredibly insignificant as to be irrelevant).

    It's pretty much a matter of taste.

  • Mike (unregistered) in reply to hunter9000
    hunter9000:
    Anon:
    Why? Hashtable and Vector are the classes you want when you need synchronized access to them for access to multiple threads.
    No, there's still no reason to use the legacy classes. You can create synchronized versions of any Collection using the Collections.synchronizedXXX() method. http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html

    Bah! My post was in reply to this.

  • Some Scientist (unregistered)

    This is the difference between a coder and a computer scientist. James should be forced to retire from the field, or at least be required to wear a blaze orange vest at all times to let you know he's a hazard to codebases everywhere.

    'Computer Science' is such a bad term; it's like calling surgery 'Knife Science' or astronomy 'Telescope Science'.

  • Ryan (unregistered)

    "Oh.. i see what you did here.. Okay, we have two arrays.. alright.. and we have.. uh.. uh.. you're fired."

  • barfman (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?

    heheheheh, "first" was actually funny for once!

    Ahh, but I find that walking, I use headsets, a watch, and constantly find myself checking out pretty girls.

    I figured sitting on my ass in a white padded room would be even more efficient...

    Now, time for some time-space traversing transcendental meditation... :|

  • Anonymouse (unregistered) in reply to Reaver
    The hard part of memory management in C/C++ isn't when you call malloc/realloc/calloc/new, but when you call free/delete. Especially when you have multiple threads.

    Absolutely correct!

    Cheers!

    Cowards.

  • Asd (unregistered)
    The benefit of deprecating those classes is minor, while the cost is major: it would require a lot of people to rewrite a lot of old code, and many Java APIs would need to have methods added which use List/Map/Iterator.
    Deprecated code is not removed. They would just get warnings and would not need to rewrite anything. Unlike stupid changes like introducing the assert keyword which broke lots of code.
  • Anonymouse (unregistered) in reply to Reaver
    The hard part of memory management in C/C++ isn't when you call malloc/realloc/calloc/new, but when you call free/delete. Especially when you have multiple threads.

    Absolutely correct!

    Cheers!

    Cowards.

  • Fedaykin (unregistered) in reply to Devek

    Huh? You don't need to know how something is implemented in Java, C#, etc. For example, look at Java Collections. I don't need to know the implementation differences between a Set an ArrayList or the Tree* versions of those classes, I just need to know when it is appropriate to use one over the other. Understanding the usage of something doesn't require that you know how it's implemented.

  • Anonymouse (unregistered)

    About this idea of not hiring experienced coders because they tend to be arrogant. You are aware that there's a huge difference between actually being arrogant, and being perceived as such because of superior experience.

    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.

    Of course you want the guy who doesn't reinvent perfectly good existing classes, before you want the guy who does so in an extremely clever but too time-consuming way. But either is preferable to a man who can't code. The seemingly infinite amounts of incredibly poor software that roams the world today is largely the result of incompetence, not surface arrogance.

  • bah (unregistered)

    I think the best part is.. that thing isn't even a hashtable.. It's just a key/value pair array!

  • bah (unregistered)

    I think the best part is.. that thing isn't even a hashtable.. It's just a key/value pair array!

Leave a comment on “It Had Too Many Functions”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article