It is 2016, why does Java still shit itself like a baby if you try to serve a non-toy amount of traffic with it without tuning your garbage collector settings yourself like some sort of caveman?
Is it so hard to set defaults that don't randomly freeze like a deer caught in the headlights at the sight of multiple qps?
What's that OP? Are you saying that an automated function that's tuned for the general case isn't supremely efficient for a specialized case? I'm so sorry OP, have my condolences.
Name:
Anonymous2016-02-27 17:33
OP here, update: it turns out you just can't get acceptable performance no matter what. You need to buy a proper GC for $$$ or just make sure not to allocate any objects ever. Good game, Java, "Just as fast as explicit memory management" my ass.
>>10 Listen up, you stupid fuck. If you're allocating/freeing all over in C that'll add a ton of slow overhead to your program. You need to buy a proper GC for $$$ or make sure not to heap allocate any objects ever. GC is just as fast/slow as explicit memory management, because you underestimate how shit slow the heap is in other languages. If memory management overhead is a problem in any language, you have to do the avoid allocation dance.
Now, go kill yourself.
Name:
Anonymous2016-02-27 19:19
>>12 In C you get to choose whether the object goes on the stack or the heap. I don't believe Java gives you a choice. You could be doing something that, in C, lives entirely on the stack, but outside of C, you are at the mercy of the runtime.
Now, go sit in the corner and think about how you could make an ill-considered point without sounding like a condescending dumbass.
Name:
Anonymous2016-02-27 19:22
>>13 If you don't understand the situations in which your runtime can decide to stack allocate, you do not deserve to attempt programming. Again, your suicide is overdue. Get on it.
Name:
Anonymous2016-02-27 19:32
>>14 You misunderstand. First, I am not >>1. Second, if the set of situations in which your runtime can decide to stack allocate are empty, then you can never make sure not to heap allocate any objects ever. Thus the C-ist's "just don't malloc, dumbass" argument is void. If that isn't the point you were making, then the only other interpretation of >>12 is just a vapid rewording of >>10, but slightly generalised and with pointless beratement chucked in.
Name:
Anonymous2016-02-28 3:15
>>12,14 You are defending Java, an abandoned piece of shit that's owned by Oracle, not the latest development in programming language research.
>>24 Don't fear the NOMAD. Let the HASKAL in your program.
Name:
Anonymous2016-03-01 6:39
>>27 It's not nomads I fear, it's all those fucking monads I'd need just to access a variable.
Name:
Anonymous2016-03-03 20:24
>>28 There are no variables. Just values, bindings and thunks.
Name:
Anonymous2016-03-03 20:30
>>29 You mean, there are no assignables. Haskell has plenty of variables.
Name:
Anonymous2016-03-03 20:32
>>30 Sure, they vary, but are you sure that's not only in your mind?
Name:
Anonymous2016-03-03 20:39
>>31 A variable is, by definition, an immutable thing that cannot vary. So of course Haskell variables, being actual variables and not some imperative scam, do not vary.
Name:
Anonymous2016-03-03 20:41
>>32 Actually, I'm pretty sure Haskell has had mutable constants for a few years now.
Name:
Anonymous2016-03-03 20:52
>>33 Those are immutable references, and different from imperative assignables which are mutable and thus not variables.
Name:
Anonymous2016-03-03 20:59
>>34 But you have to assign a constant in the first place, otherwise it has undefined value. Did you mean constant references, which are an variable pointing immutably to a specific datum?
But white people can't be racist, only minorities are.
Name:
Anonymous2016-11-10 17:27
>>12 Don't bother with the heap, stack memory is faster.
>>13 Java puts class objects on the heap, and primitives and references on the stack. You can put primitives on the heap using boxing, though you can't easily put objects on the stack.
gasTheKikes = do ... is a constant, not a variable.
Name:
Anonymous2016-11-13 11:26
>>39 Yes, a variable, by definition, cannot vary. When you write an equation like x - 1 = ln x, it will only have meaning if the second x is exactly the same as the first x. In fact, imperative languages have variables too - the function arguments. The imperativists' error is that the other things they call variables - like local or global assignables - are not variables at all because they are mutable and a variable is immutable. Like, by definition.
Name:
Anonymous2016-11-13 11:34
>>40 Variables don't vary because they are unknown consts. Which you would know if you had even school-level mathematical education. But no, you chose to be a coder, and coders don't need all this mathematical bullshit, do they?
Name:
Anonymous2016-11-13 11:53
>>41 Variable literally means 'able to vary'. And in most imperative languages, an equation like you wrote wouldn't be valid except in a condiational statement. There's basically three meanings of the = sign. In math, it is creating a constraint, STATING THAT the two sides are equal. In programming, it is either used as a test (ASKING IF the two sides are equal), or as assignment (indicating a change of state). The assignment statement has restrictions compared to the other uses, namely the left-hand side must be an object, not an expression or literal value. It is inherently directional, as left = right means "set left to the value of right". Mathematical equality is declarative, not imperative. X = Y is just saying that a constraint must be met, not how that constraint should be met if X and Y are not currently equal. Imperative programming requires defining a dependent variable, which cannot always be determined by looking at an equation.
Name:
Anonymous2016-11-13 12:15
>>43 Your opinions on syntax are absolute rubbish. I'll let you check you my dubs anyway.
But not between instances of itself. I.e. in any equation/proof/term all instances of a variable must be strictly equal. No variability at all. If it varies, it's not a variable but a mutable assignable.
And in most imperative languages
So you are completely mathematically ignorant, right? Don't even know what an equation is? Why don't you go sweep the streets, you imperative ignoramus?
Name:
Anonymous2016-11-13 17:33
>>45 It can vary over time, instances are irrelevant. A variable is a designated area of RAM (or possibly a register, IO port, or whatever), it can only hold one value at any given time.
Variables have nothing to do with RAM. I already told you that imperative languages have one example of a variable - the function parameters, but you couldn't even understand that. Or maybe you are numbskull enough to believe that function parameters are pieces of memory. Either way, off to sweep the streets and take out people's trash you go, ignoramus. You have no place anywhere near a compiler.
Name:
Anonymous2016-11-13 17:57
Perhaps "unknown const" is the best idea of a variable that an imperative ape can have.
Like, it's immutable, you know. But we don't actually know it. Could be anything, as long as it's this type, right? Like, you diggin what I'm telling you, bruh? So a variable is a const, you gettin that, dawg? A const. Yes. Like, it doesn't vary the way usual assignables vary, right? It's a const. But it varies because we, like, can substitute any const in its place. Cuz it's unknown and shit? So yeah, like a const but we don't know it. But still unknown. So, uh now you've been redpilled as far as these things called variables go, yeah, gimme a high five bruh!