Quote:Original post by no such user You chose to use a harder programming language, and then you bitch because the problem is harder with the harder programming language. That's just silly. The difference between C++ and higher level languages is more than just manual memory management. If you can't realize that then it does reflect negatively on your programming ability.
I'm not bitching because it's harder. I'm not really bitching at all. It's a practice test that took me 10 minutes.
Just pointing out a flaw where someone who picks a harder language will be ranked lower despite having code that is practically the same skill wise or even shows significantly more skill.
Right, three posts in the row about the same issue isn't bitching. Sorry, choosing the right tool for the job is part of programming skill. If you choose a low level programming language for the job, you're saying that you can make decisions about all those low level details correctly. That includes what data types you make your variables.
Quote:Original post by no such user Right, three posts in the row about the same issue isn't bitching.
not really no...
Quote:
Sorry, choosing the right tool for the job is part of programming skill.
so you are recommending someone with no python experience switch to python for a job application screening test with a time restriction because python has some features that make it safer for a very specific and extreme use case?
Here's a real life scenario: you get told to create a tool that processes a file, and the basic algorithm that goes into it. You aren't told what each and every customer will use as an input into that file. If your tool can't process a really long file, you can't say that it's unfair that a customer fed it a really long file because you used C++ and didn't anticipate needing a large number data type. Instead you have a bug that you need to fix. Period. If you use an O(n2) algorithm and your program takes three hours to handle what a customer considers a reasonable file size, you might get another bug report. Or that customer might just use someone else's product and never inform your company about it. Yes, it may seem unfair that you don't get all the inputs for everything. That's real life in software development. You will regularly be expected to write your best code without knowing all the criteria that will be used to judge it. The people handing you that assignment won't know all the criteria that will be used to judge it. Even if you are sitting down with the customer, and they lay down everything they think should go into a program, they will forget things. Or assume because they said A, B and C that you would do D. You will regularly get customers who give you sample data sets of only one hundredth or one thousandth the size of the average actual data sets they want to work with. Those "extreme" use cases? They're the norm.
Personal story: one of the first programs I wrote for someone else that got used publicly was a score tracking application for a tournament. I was told that every round has four teams, and coded the program accordingly. However, during the actual tournament some rounds only had two or three teams. My program did not function cleanly in those situations. It actually displayed -666 as the team names for the empty teams, as that was a number used as an error code that got propagated outwards. Needless to say, some of the contest supervisors were not amused. Yes, the program handled every usage scenario I was given; however, at the end of the day, the quality of my code was judged by scenarios I wasn't given.
I was so worried that quotes had gotten totally messed up on GDnet. I don't know how I missed that this was an uber necro. I'm just so happy quotes aren't broken.
