|
this is from my comp sci grad school partner's code for "parsing" an XML dataset and returning information. I don't think this is really falling under the "student code" provisions of this thread since we both are getting a part time degree while working full time in software for the last 7 years.code:
- single quotes - a space between the content and the closing angle bracket which means like half the totally valid xml we have just doesn't get read The date in the files are "<year>:<month>:<day>:<hour>:<minute>:<second>" which is fine and normalized, so I'm confused why the hell he's reinventing the wheel on epoch time: {code} *date = (year-1970)*365*24*60*60 + (month-1)*30.4328499*24*60*60 + (day-1)*24*60*60 + hour*60*60 + minute*60 + second; {code} That 1970 apparently got tacked on after I told him that seconds from year 0 was bad idea always and especially when all of data was after 2005. And 30.4328499 is a HELL of a magic number for the "average days in a month" which I don't think is even correct. #if/#endif as flow control apparently? too lazy to comment out debug code? YOU DECIDE! Also he checked in a 700 MB tarball into our mercurial repo and out of all that we're going to use 46M (uncompressed) worth of static, unchanging xml only edits are new lines for table breaking --- The point of this C script is to count items that occur on a date and within a radius of a given lat/long, and return the results, meaning that the xml is going to be parsed 100s of times without ever changing. That should really be a relational database holding the parsed XML data and we could make queries against it, but I'm so close to just closing out this project and being done with the class I just don't feel like doing the right way. When I gave him this portion I knew in order to not worry about it, I was ceding control and had to be willing to live with "functional but not usable" VVV who the hell knows argggggggg Lurchington fucked around with this message at 01:06 on Nov 26, 2011 |
# ? Nov 25, 2011 11:23 |
|
|
# ? May 31, 2024 03:50 |
|
Why do those printf lines have 75 spaces after them?
|
# ? Nov 25, 2011 11:29 |
|
Lurchington posted:And 30.4328499 is a HELL of a magic number for the "average days in a month" which I don't think is even correct. It's not far though (((365 * 4) + 1) / 4) / 12 = 30.4375 VVVVV Oh, right. I forgot about century leap years. The fact I'm having this conversation feels very wrong. Pollyzoid fucked around with this message at 14:43 on Nov 25, 2011 |
# ? Nov 25, 2011 13:12 |
|
Pollyzoid posted:It's not far though (365 * 400 + 97) / (400 * 12) = 30.436875 I think you'll find.
|
# ? Nov 25, 2011 13:40 |
|
perl ownscode:
|
# ? Nov 25, 2011 16:08 |
|
edit: mmnngn
|
# ? Nov 25, 2011 16:46 |
|
Here is a java one from Games forum superstar java programmer Notch. It made my head hurt trying to follow it in the obfuscated code. (there was more jumps that led me to this, renames are mine) Old method: code:
code:
|
# ? Nov 25, 2011 18:59 |
|
code:
Does this make as little sense as I think it does?
|
# ? Nov 25, 2011 23:05 |
|
Optimus Prime Ribs posted:
Yep.
|
# ? Nov 25, 2011 23:08 |
|
Optimus Prime Ribs posted:
It was obfuscated, I have no idea what it was called or what its purpose is, but I can't think of basically any good reason. Here was my logic for what probably happened: Notch: I think this method should take 3 color args for RGB even though it only needs two, because consistancy for color methods (Okay I will buy this) Oh drat, it gave me a compiler warning because I don't use the argument anywhere in the method. Well, if I just write a quick useless method that uses the arg, then I can get rid of the compiler warning! (Gone into insanity) EDIT: Original decompiled, deobfuscated looks like this: code:
Salynne fucked around with this message at 00:16 on Nov 26, 2011 |
# ? Nov 26, 2011 00:11 |
|
Well that certainly is something.
|
# ? Nov 26, 2011 00:32 |
|
General Olloth posted:It was obfuscated, I have no idea what it was called or what its purpose is, but I can't think of basically any good reason. For confusing people looking at decompiled code, perhaps. At runtime it's just going to be inlined (JIT allows inlining of virtual methods with only one implementation in practice) and then eliminated entirely. So performance-wise, it's pretty close to zero cost and there's a definite nonzero cost for anyone trying to decompile and understand the code. I haven't messed around with obfuscators enough to tell if that's something commonly done, but there's nothing technically preventing it.
|
# ? Nov 26, 2011 12:52 |
|
It's probably also been optimized, so the original could look more like this:code:
|
# ? Nov 27, 2011 02:14 |
|
Here's some article I read: "Yoda Conditions", "Pokémon Exception Handling" and other programming classics
|
# ? Nov 27, 2011 21:30 |
|
1337JiveTurkey posted:For confusing people looking at decompiled code, perhaps. At runtime it's just going to be inlined (JIT allows inlining of virtual methods with only one implementation in practice) and then eliminated entirely. So performance-wise, it's pretty close to zero cost and there's a definite nonzero cost for anyone trying to decompile and understand the code. I haven't messed around with obfuscators enough to tell if that's something commonly done, but there's nothing technically preventing it. I don't think the obfuscator he uses does this but I could be wrong. I have "insider information" from the Bukkit team who has/had access to his real source that it is just as insane in many places. The only thing his obfuscator seems to do is put all the classes in one package (3000 classes in the same package, that's fun) and rename everything to jibberish.
|
# ? Nov 27, 2011 22:30 |
|
General Olloth posted:The only thing his obfuscator seems to do is put all the classes in one package (3000 classes in the same package, that's fun) and rename everything to jibberish. code:
code:
(This doesn't absolve notch from not just calling this.biomeCache.useColor(red, blue) in the first place :o)
|
# ? Nov 28, 2011 03:55 |
|
The Gripper posted:(This doesn't absolve notch from not just calling this.biomeCache.useColor(red, blue) in the first place :o) I think the argument was that if you use three arguments then he can make it depend on green without refactoring every single reference.
|
# ? Nov 28, 2011 04:04 |
|
Also Thing.thingWithColor() is a lot better than Thing.biomeCache.useColor(). For one, biomeCache should be private.
|
# ? Nov 28, 2011 05:47 |
|
Dessert Rose posted:Also Thing.thingWithColor() is a lot better than Thing.biomeCache.useColor(). For one, biomeCache should be private.
|
# ? Nov 28, 2011 08:01 |
|
I did not know Java generics were this bad http://a-dimit.blogspot.com/2011/11/re-highbrow-java-or-java-generics-and.html Give me C++ templates or give me death.
|
# ? Nov 28, 2011 14:44 |
|
Zombywuf posted:I did not know Java generics were this bad http://a-dimit.blogspot.com/2011/11/re-highbrow-java-or-java-generics-and.html This is just my Stockholm syndrome, but it's much better than the poo poo we had to do before. Also of all the things he mentions the only one I've ever run into is trying to create a generic array, so meh.
|
# ? Nov 28, 2011 16:34 |
|
MEAT TREAT posted:This is just my Stockholm syndrome, but it's much better than the poo poo we had to do before. Also of all the things he mentions the only one I've ever run into is trying to create a generic array, so meh. Java generics are terrible but mostly from a theoretical pov. For the day to day "I'm a 2010-era COBOL programmer" they're perfectly fine. No one working in the salt mine really gives a poo poo about how Java-style generics work.
|
# ? Nov 28, 2011 18:32 |
|
They're an utterly terrible piece of poo poo if you're used to C++.
|
# ? Nov 28, 2011 18:56 |
|
Zombywuf posted:
the thing I ran into a lot was attempting to overload on instantiated generic types -- you can't have a function that overloads different behaviors on a ArrayList<Foo> vs. an ArrayList<Bar> because they have the same erasure.
|
# ? Nov 28, 2011 19:00 |
|
TasteMyHouse posted:the thing I ran into a lot was attempting to overload on instantiated generic types -- you can't have a function that overloads different behaviors on a ArrayList<Foo> vs. an ArrayList<Bar> because they have the same erasure. Just give the methods different names if they have different parameters. In this case having the information at runtime still wouldn't help because overloaded and static methods are always resolved with the declared types at compile time.
|
# ? Nov 28, 2011 19:17 |
|
1337JiveTurkey posted:Just give the methods different names if they have different parameters. doesn't work with ctors :P
|
# ? Nov 28, 2011 19:33 |
|
TasteMyHouse posted:doesn't work with ctors :P Try a static factory method then. Overloading based on the generic parameter of a method is just going to confuse the crap out of people, especially if they think the type is covariant on its parameter.
|
# ? Nov 28, 2011 19:43 |
|
TasteMyHouse posted:the thing I ran into a lot was attempting to overload on instantiated generic types -- you can't have a function that overloads different behaviors on a ArrayList<Foo> vs. an ArrayList<Bar> because they have the same erasure. Wasn't there some supertype of Foo & Bar that you could have used?
|
# ? Nov 28, 2011 19:46 |
|
You can't overload on ArrayList<FooBarSupertype> either
|
# ? Nov 28, 2011 19:48 |
|
1337JiveTurkey posted:Try a static factory method then. Overloading based on the generic parameter of a method is just going to confuse the crap out of people, especially if they think the type is covariant on its parameter. yeah, I think I ended up doing something like this. Still, struck me as weak as hell that I had to make functions like MakeThingFromFooContainer(Container<Foo> p) and MakeThingFromBarContainer(Container<Bar> p).
|
# ? Nov 28, 2011 19:57 |
|
pseudorandom name posted:You can't overload on ArrayList<FooBarSupertype> either You wouldn't overload in that case. Change the class to something like this: code:
|
# ? Nov 28, 2011 20:17 |
|
TRex EaterofCars posted:Java generics are terrible but mostly from a theoretical pov. For the day to day "I'm a 2010-era COBOL programmer" they're perfectly fine. No one working in the salt mine really gives a poo poo about how Java-style generics work. Java developers don't seem to give a poo poo about endless amounts of duplicated boilerplate so it's not surprising that they don't care about problems with a feature useful for cutting down on that.
|
# ? Nov 28, 2011 20:20 |
|
Zombywuf posted:I did not know Java generics were this bad http://a-dimit.blogspot.com/2011/11/re-highbrow-java-or-java-generics-and.html The Java array design would be totally different if generics had existed from the beginning; the possibility of polymorphism over array types would make it acceptable to eliminate the covariance rule for array types, and element types would probably be subject to the same erasure rules as everything else. C++ only kindof-sortof overcomes the code/metadata bloat of templates; Java would have a much harder time of it, and I'm not offended enough by the lack of enforcement of generic casts to think that's a good price to pay.
|
# ? Nov 28, 2011 20:43 |
|
I think C# does a reasonable job of it. You can't do the nearly as much with C# generics as with C++ templates, but unlike Java it doesn't have type erasure, so generics make sense and don't need heaps of stupid casts everywhere. It still managed to inherit the array covariance misfeature though.
|
# ? Nov 28, 2011 21:02 |
|
The last page reaffirms my belief that Java itself is as much of a horror as PHP and I'm justified in having plausible deniability about anything related.
|
# ? Nov 29, 2011 00:12 |
|
NotShadowStar posted:The last page reaffirms my belief that Java itself is as much of a horror as PHP and I'm justified in having plausible deniability about anything related. I don't know if this is the case. PHP gives you a bunch of horrors by default, a set of mostly broken tools to try and fix them, and documentation and a community that either pretends the problems don't exist or gives bad advice as to how to fix them. The most commonly trotted out example of this would be the addslashes()/magic_quotes/mysql_escape_string()/mysql_real_escape_string()/mysqli_prepare() debacle. Java on the other hands gives you a bunch of inconvenience by default, a set of mostly broken tools to try and make things less verbose or more convenient, and documentation and a community that either pretends the language isn't verbose and generally inconvenient or pretends this is an advantage. If given the choice, I would always choose the latter over the former.
|
# ? Nov 29, 2011 00:39 |
|
Isn't that the programming language equivalent of saying Hellraiser 3 can't be a bad film, because The Gingerdead Man is a really bad film? Luckily enough, more than two options exist, and in the context of all of them, both are not too great.
|
# ? Nov 29, 2011 01:18 |
|
rjmccall posted:The Java array design would be totally different if generics had existed from the beginning; The idea of arrays having a design that prevents this kind of polymorphism boggles the mind. On the plus side, I now know why Java coders get angry when you mention type erasure.
|
# ? Nov 29, 2011 01:24 |
|
NotShadowStar posted:The last page reaffirms my belief that Java itself is as much of a horror as PHP and I'm justified in having plausible deniability about anything related. Really? You think that Java's jacked up Generics and array semantics, caused by conscious decisions to maintain backwards compatibility are even in the same ballpark as PHP's travesty of engineering? I mean don't get me wrong, writing Java sucks as much as slogging through a swamp for sure, but the lead designer of PHP literally goes out of his way to eschew computer science, and Java has been worked on by some of the greatest minds in the field. I don't really see how they can be compared in that manner.
|
# ? Nov 29, 2011 02:01 |
|
|
# ? May 31, 2024 03:50 |
|
Zombywuf posted:The idea of arrays having a design that prevents this kind of polymorphism boggles the mind. My understanding is that they had a problem, a deadline, and subtype polymorphism. Parametric polymorphism is more appropriate, but it's also a much more complicated language feature, particularly if you don't want "instantiations" to require independent type-checking. I mean, Java's generics support is already too sophisticated by some metrics — most programmers don't understand the mathematics and just work around (misuses of) the type system with casts. And there's a lot more yet that Java generics can't express, like the co-/contra-variance of List<T> with T.
|
# ? Nov 29, 2011 02:17 |