| « Prev | Page 1 | Page 2 | Page 3 | Next » |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:05
•
by
dkfal
(unregistered)
|
|
wtf???
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:07
•
by
Anthony Shaw
(unregistered)
|
Agreed... WTF?! And why wouldn't you just case the string? |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:10
•
by
mdkess
(unregistered)
|
|
Hey, at least they used comments.
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:12
•
by
Goldie
|
because java doesn't support switching on a string, or indeed anything else except numbers and enumerations that said, it's still a dunbass way to do this. What's wrong with if else if else if else if else if or some kind of mapping ? |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:12
•
by
diaphanein
(unregistered)
|
My guess is a newbie to C# and wasn't aware of the capability. You cannot switch on strings in say, c++ or c. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:13
•
by
htg
(unregistered)
|
You can't in Java. However for most apps where the first character of the argument is unique you could switch on the first character of the argument ... ... if you really wanted to optimise something that runs just once per application run. For command line argument parsing, just write something reasonably concise but very readable and uniform, throwing a few clock cycles away on doing string comparisons for all the possible arguments is not a big issue. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:20
•
by
Volmarias
|
|
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Code Complete, Page 594)
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:27
•
by
Coincoin
(unregistered)
|
|
Possibilities:
1) The programmer was told by an overzealous ignorant teacher that if-else-if-else are bad and we should ALWAYS use switch instead. I swear, I lost points in a term lab because of that and the teacher wouldn't give my points back and even threatened to make me fail if I insisted. The funniest thing is I had to make range comparisions which were impossible in switch statements for that language. or 2) A h4x0r friend told him "hash are faster" and he blindly applied his elite advice without realising it was like racing to catch the next red light faster. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:39
•
by
Telimaktar
(unregistered)
|
|
Painful!
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:39
•
by
wtf
(unregistered)
|
|
omgwtf i think i've seen this before lolol!!!11!
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:50
•
by
rbowes
|
|
I hate to admit it, but I've done that before. It's been a long time, and I was pretty new to programming back then, but it really seemed like a good idea at the time. Somehow...
I don't appear to have the code for it anymore, though. I probably deleted it in shame. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:52
•
by
Devi
|
That's what happens when a Teacher thinks maintaining their own authority is more important than their students getting accurate information and understanding. I once got into detention at school because of an argument with my science teacher about convection. She said hot air rose because it was lighter than cold air, I said it rose because the heavier cold air was pulled beneath it by gravity and pushed the hot air upwards. Being an arrogant little ***** I refused to back down and spent 3 hours writing lines for my trouble. There was also that story going round about the student who had a letter sent home because they insisted to their teacher that a mile was longer than a kilometer, but I can't find the link... |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:58
•
by
sir_flexalot
|
|
now that is classic!
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 09:59
•
by
PAG
(unregistered)
|
|
hehehe, I've done that in plenty of ways in my contest submission ;-)
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:01
•
by
TheRider
|
What a great way of thinking. Looking at it that way never occurred to me so far. Absolutely brilliant! But, aren't these two views just two sides of the same coin? (Yes, I *do* understand that the former is a rather simplistic view oriented towards our "everyday life experience" whereas the latter is a more scientific view reflecting actual laws of physics.) |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:15
•
by
Greg
(unregistered)
|
Actually, you were both wrong. It has to do with density. The same reason oil floats on water. Hot air is less dense than cold air because the air molecules have more energy, etc etc. Bust out a physics book. CAPTCHA: poindexter (how appropriate) |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:18
•
by
htg
(unregistered)
|
|
[quote user="Devi"][quote user="Coincoin"]
I once got into detention at school because of an argument with my science teacher about convection. She said hot air rose because it was lighter than cold air, I said it rose because the heavier cold air was pulled beneath it by gravity and pushed the hot air upwards. [/quote] 1kg of hot air weighs the same as 1kg of cold air :p Hot air rises because it is less *dense* than cold air, and gravity forces the more dense gas under the less dense gas. Hey, if you want to be pedantic! The lazy, slow unenergetic particles are hunting for a sofa, pretzels and beer, whilst the energetic fast particles are off achieving great things. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:19
•
by
htg
(unregistered)
|
Gah, I knew I should have replied before replying to that (stinky) email. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:20
•
by
ash
(unregistered)
|
|
Depending on what this person was trying to do, a command pattern and/or Apache Commons CLI (something equivalent) could be helpful.
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:27
•
by
AdT
(unregistered)
|
Good morning. This is Java, as evident in the String.toCharArray method (note the small t) and the syntax for the "args" parameter (in C#, only "String[] args" is legal). |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:33
•
by
Devi
|
Be quiet! Any more of that lip and you're gonna be staying late after class for the next week, buddy! |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:37
•
by
J.
(unregistered)
|
I've had the opposite. One of my university lecturers in introductory programming told us using switch was bad because "it's almost like using goto". I stopped attending his lectures after that. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:41
•
by
Kid
(unregistered)
|
Perhaps, but that's not the best way to look at it. If you're talking density, then you're talking weight over an area, not for a given mass. So, to more accurately match the rest of your argument, you have to say: 1 cubic foot of cold air weighs more than 1 cubic foot of hot air, at the same pressure. So, it *generally* floats on the cold air (since there are times when it does not - ref thermal inversions). Still the code is quite the WTF. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:49
•
by
akatherder
|
|
Here's the letter about a km being longer than a mile:
http://www.snopes.com/humor/letters/hilliker.asp |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:49
•
by
bonzombiekitty
|
But one cubic meter of hot air will weigh less than one cubic meter of cold air under the same pressure.
And it's less dense because the same volume of air under the same pressure weighs less when it's warm. Saying hot air weighs less than cold air is a very simplistic way of saying that hot air is less dense than cold air. ETA: Do'h looks like someone else said pretty much the exact same thing I did. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:52
•
by
pgaule
(unregistered)
|
|
If you use a switch statement with "break", then technically the "break" is like a "goto" statement, in the sense that it tells the program to branch to *after* the switch statement.
However, that doesn't make it evil. In addition to using them in a switch statement, I've had times where I needed to use a "break" statement to save myself from iterating through some structure more than neccessary. When Dijkstra wrote his paper about how "gotos are teh suck!", I doubt he was referring to stuff like "break", but more for the masochists that emulated loops with if statements and gotos. Those are extreemly unreadable and prone to error compared to traditional loop structures. On the other hand, any idiot who has been through an introductory programming course probably is farmilliar with how a switch statement works. They are pretty simple. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 10:52
•
by
pgaule
(unregistered)
|
|
If you use a switch statement with "break", then technically the "break" is like a "goto" statement, in the sense that it tells the program to branch to *after* the switch statement.
However, that doesn't make it evil. In addition to using them in a switch statement, I've had times where I needed to use a "break" statement to save myself from iterating through some structure more than neccessary. When Dijkstra wrote his paper about how "gotos are teh suck!", I doubt he was referring to stuff like "break", but more for the masochists that emulated loops with if statements and gotos. Those are extreemly unreadable and prone to error compared to traditional loop structures. On the other hand, any idiot who has been through an introductory programming course probably is farmilliar with how a switch statement works. They are pretty simple. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:07
•
by
gusmao
|
|
There is yet another gotcha. Since the return value of hashfunctions may collide, depending on the values of the String passed as argument he can have two different options being resolved into the same case.
Granted, that's unlike to happen, but it nevertheless can introduce a very subtle and pernicious bug into the program. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:19
•
by
Devi
|
Would it even compile though? C++ throws an error with two identical case values in a switch statement... That is the horrible thing about hash systems though, I often use a crc32 algorithm to hash strings to make identifiers for class instances/whatever. So far I've never had a single collision (I'm guessing the chances are 1 to 2^32 against, but I'm probably wrong) but one day it'll happen, and everything will go bang... |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:19
•
by
Will
(unregistered)
|
I was scolded twice by my fifth-grade teacher for saying that 2 was a prime number. She held that it was a composite number "because it was even." |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:25
•
by
eo
(unregistered)
|
|
actually, tony hoare, restated by knuth
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:31
•
by
Strider
(unregistered)
|
Caught in that situation, my head would have simply exploded. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:34
•
by
Devi
|
The one that always upset me was one, I mean the rules say it must be "Only divisible by itself and one", some people seem to think it gets disqualified because itself and one are the same thing. Like it's cheating and has an unfair advantage or something... |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:34
•
by
htg
(unregistered)
|
Did I say that 1kg of hot air was going to occupy the same volume of space as the 1kg of cold air? No. I was responding to the original poster with a jokey comment because he was trying to be pedantic to his teacher, but was just as wrong because he used weight (I assume he meant mass of course :p). You're trying to come back with me using an argument which was what I was using against the original poster, namely that it's density we car about, i.e., mass/volume, not weight!
So you've got a fixed volume, and a fixed pressure, and you're heating up the air and the pressure or volume aren't changing? Damn those physical laws, damn them! |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:37
•
by
TheBigYin
|
|
"Depending on what this person was trying to do, a command pattern and/or Apache Commons CLI (something equivalent) could be helpful."
When someone says "a command pattern could help" that's the time I reach for my revolver. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:37
•
by
psmears
(unregistered)
|
heh... I was humiliated in front of the class for drawing the resistor in the wrong place in a (series) resistor-battery-LED circuit. Apparently the resistor only works if it's attached to the "+" side of the battery, to reduce the current *before* it gets to the LED. I'm still not sure what would happen to the build-up of electrons who, having travelled at full speed through the LED only then got slowed down by the resistor... a big build-up of charge on one leg of the LED perhaps? |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:39
•
by
Devi
|
You can do it if you reduce the mass of gas present in the volume. (Damn, I still haven't changed, even after all these years...) |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 11:41
•
by
GettingJaded
(unregistered)
|
|
LED would fry most likely.
The LED will only drop a certain voltage, and not change the current. If the current is too high, the LED will burn out, causing that ever lovely smell of burned silicon. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:15
•
by
ToxikFetus
(unregistered)
|
According to the original poster, this was a simple resistor-LED-battery circuit. It doesn't matter where you put the resistor, the voltage drop across each element remains the same. Thus, the current through each element is fixed, meaning the LED would fry or not fry in any configuration, depending on the component values. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:15
•
by
KM
(unregistered)
|
One is in fact not a prime number. It's a unit. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:22
•
by
J.
(unregistered)
|
Is that when you are supposed point out that the electrons go from "-" to "+"? ;P |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:34
•
by
gusmao
|
|
It will compile because the switch will only have a single number case, the bug is on the fact that two different Strings may be resolved into the same case.
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:42
•
by
Will
(unregistered)
|
That is incorrect. The "rules" say that a prime number is a natural number with exactly two distinct factors. One has only one factor — one — and is therefore not prime. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:44
•
by
nobody
(unregistered)
|
|
So what was the person who wrote this code smoking?
|
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:44
•
by
tyler
(unregistered)
|
|
I can't believe they did it that way.
It's kind a joke working like that |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 12:50
•
by
xix
(unregistered)
|
|
I always go by the prime decomposition. 1 is an irritating prime since then you have an infinite number of prime decompositions for any composite number. 1 itself it not prime, nor is it not prime since it's decomposition is just itself, so one is the special.
Now 2, just ask the teacher for the multi-term prime decomposition of 2. captcha: burned (well, quite) |
|
I'm sure we've all used the strings(1) command on an executable to see what else is in there.
If there are command line options that are secret except for your alpha testers, this would hide them. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 13:23
•
by
Will
(unregistered)
|
I agree with you in principle, though I'm going to argue with the terminology you're using. 1 is not prime, for the reason I said above. However, when you say "nor is it not prime", you're actually explaining why it's not composite. It's possible for a number to be neither prime nor composite. One is an example of such a number, as is zero. And, of course, any non-integer or negative integer. |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 13:51
•
by
max
(unregistered)
|
If else if else if else hoses the pipeline a lot with branch instructions. There really isn't anything WTF about this except that it's horribly horribly undocumentable and terrible to maintain. It'd be better to have a hash table of function pointers, and have the function pointers have descriptive names. Captcha: muhahaha. My sentiments exactly! |
Re: Classics Week: How Not to Parse Command Line Arguments
2007-05-08 14:21
•
by
Rich
(unregistered)
|
|
I remember when this came out the first time. I;m surprised no one has commented on the fact that hash algorithms may be changed, and therefore this is a bad way to check on a string. I'm not a java maven, but i think the String.HashCode algorithm has changed somewhere in the course of it's evolution.
|
| « Prev | Page 1 | Page 2 | Page 3 | Next » |