|
evensevenone posted:it's the end of the quarter, and I already wrote transpose, so why waste time? were you that rear end in a top hat who got 100 on the first midterm
|
# ? Nov 29, 2010 05:36 |
|
|
# ? May 16, 2024 18:23 |
|
98 I thought a lot of people got 100s though.
|
# ? Nov 29, 2010 06:22 |
|
Internet Janitor posted:poor spelling certainly is a pro trait. the keystroke commands simply execute out of order because the parallel hardware can't guarantee consistent interleaving without expensive locking operations
|
# ? Nov 29, 2010 20:14 |
|
I present Groovy's ArrayUtil.javacode:
|
# ? Nov 29, 2010 23:12 |
|
Java isn't my strongest language, but you can declare arrays inline like new object[] {obj1, obj2, obj3};, right? if so,
|
# ? Nov 29, 2010 23:18 |
|
Ryouga Inverse posted:Java isn't my strongest language, but you can declare arrays inline like new object[] {obj1, obj2, obj3};, right? That's exactly what createArray does internally!
|
# ? Nov 29, 2010 23:26 |
|
Ryouga Inverse posted:Java isn't my strongest language, but you can declare arrays inline like new object[] {obj1, obj2, obj3};, right? Yes, that's exactly what those methods are doing.
|
# ? Nov 29, 2010 23:26 |
|
To be fair, those methods are part of the Groovy runtime and only called by generated code. Which doesn't explain why the code generator doesn't just create the arrays inline, but it isn't like humans are actually using that abomination directly.
|
# ? Nov 29, 2010 23:53 |
|
Pardot posted:and so on up to arg249
|
# ? Nov 29, 2010 23:53 |
|
Munkeymon posted:the keystroke commands simply execute out of order because the parallel hardware can't guarantee consistent interleaving without expensive locking operations This actually happens to me when typing sometimes (the hardware is my nervous system)
|
# ? Nov 29, 2010 23:57 |
|
For what it's worth, those functions do change program semantics: they change evaluation order so that the array is allocated after the operands are evaluated, rather than before. Why that would be desireable, I don't know.
|
# ? Nov 30, 2010 01:08 |
|
Kelson posted:That's exactly what createArray does internally! Could you do something more like: code:
I'm not sure what the semantics of the variable-arity call in Java are.
|
# ? Nov 30, 2010 01:59 |
|
i'm an idiot
|
# ? Nov 30, 2010 02:03 |
|
Kilson: that's completely equivalent to the standard array-initializer expression, yes.
|
# ? Nov 30, 2010 02:04 |
|
Pardot posted:and so on up to arg249
|
# ? Nov 30, 2010 06:52 |
|
Presto posted:Should have gone to arg255. Everyone knows if you're going to pick an arbitrary point to stop at, you pick a power of 2. That way people think there's some deep-seated reason for it. It makes me wonder if they tried that and maybe there's some JVM limitation that prevents more than 250 arguments (and the difference accounts for some overhead that would add up to 255-256 somethings). I don't care enough to actually investigate this, however.
|
# ? Nov 30, 2010 17:42 |
|
Kilson posted:Could you do something more like: Yes you can. You can also sprinkle a few Generics there: code:
Flobbster posted:It makes me wonder if they tried that and maybe there's some JVM limitation that prevents more than 250 arguments (and the difference accounts for some overhead that would add up to 255-256 somethings). If I remember correctly, JVM bytecode supports up to 65536 parameters per method and 65536 methods per class. Parantumaton fucked around with this message at 18:21 on Nov 30, 2010 |
# ? Nov 30, 2010 18:18 |
|
Parantumaton posted:If I remember correctly, JVM bytecode supports up to 65536 parameters per method and 65536 methods per class. The challenge is on: somebody find a blog post containing somebody bitching about this limitation. The real ultimate horror will have been found.
|
# ? Nov 30, 2010 21:57 |
|
The zillion overloads are for performance reasons. Variable arity methods in Java are significantly slower than dispatching to a fixed-arity overload. Clojure does the same thing - the call method on whatever the basic lambda class has tons of fixed overloads with one last variable arity one to catch the rest of the cases. No idea why this particular method exists though.
|
# ? Nov 30, 2010 22:41 |
|
NotShadowStar posted:The challenge is on: somebody find a blog post containing somebody bitching about this limitation. The real ultimate horror will have been found.
|
# ? Nov 30, 2010 23:08 |
|
I found something of my own that's a small h horror but still resulted in head slapping from me. It was a quick little log viewer app that I whipped up in a couple minutes a few years ago:code:
|
# ? Nov 30, 2010 23:45 |
|
necrobobsledder posted:This is a commonly reached limitation. Usually it comes up when JSP is mentioned (although it has to do with method size limitations). That's the root of the horror. I've seen poorly written monolithic jsp's that blow past the method size limitations. I was both astounded and kind of amused; the mother fucker who wrote it was being paid over $100 an hour.
|
# ? Dec 1, 2010 00:02 |
|
Scaramouche posted:I found something of my own that's a small h horror but still resulted in head slapping from me. It was a quick little log viewer app that I whipped up in a couple minutes a few years ago:
|
# ? Dec 1, 2010 00:17 |
|
SavageMessiah posted:The zillion overloads are for performance reasons. Variable arity methods in Java are significantly slower than dispatching to a fixed-arity overload. But isn't the difference in performance there just the array creation? Which is exactly what these methods are doing in the body? I mean, you all realize that the varargs version is a no-op and would probably be optimized out by Hotspot, if not the compiler, right?
|
# ? Dec 1, 2010 00:22 |
|
Incoherence posted:I've done the "if X, do nothing, else do something" pattern before when the condition was sufficiently painful to look at that I didn't want to deal with inverting it. The else if is a bit interesting, though. I guess the best way would be to do "if Thing <> 'blah' or Thing <> 'blah blah' then DoSomething" but I guess the younger me can't think clearly (these weren't complex cases). It gets even better though, I shouldn't even have been checking for blah there anyway because the input gets scrubbed before the function starts. Basically the condition is always met. Remember kids, friends don't let friends code when they're in a hurry.
|
# ? Dec 1, 2010 00:43 |
|
Scaramouche posted:I guess the best way would be to do "if Thing <> 'blah' or Thing <> 'blah blah' then DoSomething" but I guess the younger me can't think clearly (these weren't complex cases).
|
# ? Dec 1, 2010 01:43 |
|
Okay, so do you guys know how software devs try to be cute and name their releases after random things? Like, I don't know, Antsy Aardvark, or Microsoft Excel: Charmander edition or whatever. I realize that these titles almost never relate to the actual product, but our client takes it to the extreme. I was just browsing our client's branches folder and found the part where they tag releases. There doesn't seem to be any pattern to the naming. I checked, and it isn't in alphabetical order, or by common theme, or anything. The names of their last few releases are:
|
# ? Dec 1, 2010 07:51 |
|
There's a common theme there.
|
# ? Dec 1, 2010 07:56 |
|
Is it... bad code?
|
# ? Dec 1, 2010 07:58 |
|
That, and bad movies. Maybe it's just "Name it after which movie I saw last" Also, your client is an Adam Sandler fan, by the looks.
|
# ? Dec 1, 2010 11:44 |
|
Incoherence posted:I've done the "if X, do nothing, else do something" pattern before when the condition was sufficiently painful to look at that I didn't want to deal with inverting it. The else if is a bit interesting, though. In that case why not simply do "if !X, do something"? There's no need to figure out how to invert it if you just wrap it up in brackets and throw a negation on the front.
|
# ? Dec 1, 2010 15:34 |
|
HappyHippo posted:In that case why not simply do "if !X, do something"? There's no need to figure out how to invert it if you just wrap it up in brackets and throw a negation on the front. code:
|
# ? Dec 1, 2010 18:03 |
|
Incoherence posted:Because it's usually something like Probably, but it's even easier to do code:
|
# ? Dec 1, 2010 20:55 |
|
Jabor posted:Probably, but it's even easier to do
|
# ? Dec 1, 2010 21:07 |
|
Scaevolus posted:This is a horror. Yes. De Morgan's laws.
|
# ? Dec 1, 2010 23:31 |
|
Incoherence posted:Because it's usually something like Really? If you're too lazy to work out the proper inverse !(...) seems just as clear to me as if(...){}else{...}
|
# ? Dec 1, 2010 23:47 |
|
Argue posted:The names of their last few releases are: Naming your release after the last movie you saw isn't totally unreasonable. I could see it giving a movie buff some context to help pull up associated memories.
|
# ? Dec 2, 2010 00:18 |
|
Munkeymon posted:Naming your release after the last movie you saw isn't totally unreasonable. I could see it giving a movie buff some context to help pull up associated memories. So long as that context includes the missing year of a date and missing version numbers, and said movie buff still works there, I'm with you. Maybe the Click release worked around something really annoying.
|
# ? Dec 2, 2010 01:06 |
|
Scaevolus posted:This is a horror. Inline your booleans!
|
# ? Dec 2, 2010 01:41 |
|
|
# ? May 16, 2024 18:23 |
|
Munkeymon posted:Naming your release after the last movie you saw isn't totally unreasonable. I could see it giving a movie buff some context to help pull up associated memories. I really hope you're joking/trolling here.
|
# ? Dec 2, 2010 17:42 |