World-writable memory on Samsung Android phones
Posted Dec 23, 2012 13:30 UTC (Sun) by khim
In reply to: World-writable memory on Samsung Android phones
Parent article: World-writable memory on Samsung Android phones
You clearly have no idea how complex modern JVMs are.
I know enough to hate this abomination (it promises to save development time—but then it sucks debugging time for the reasons you've outlined so well thus I'm not at all sure it's a net win), but that's not the point.
That's bordering on impossible, particularly with the server-mode JVM: you can never tell when the optimizers will kick in.
And so what? Look, if we want to write any kind of program intended to be used by non-programmer (directly or indirectly) then we need to understand how many resources it'll need. Doubly so if we can expect programmer who tries to break our creation instead (most server software for publicly accessible site). For one simple reason: resources cost money! Depending on our task 1GB of excess memory may be not a big deal (if it's a single instance on a single server) or be huge drag on the resources (if there are 100'000 nodes in use). Or it may be even a deal-breaker if we plan to support smartphones with 512MB memory.
If we can't do that for one reason or another then such program and such language can not be ever used in production because you can not predict how and when they'll fail. They can only be used in interactive development process: since failure in this case means human programmer must do something and human is resourceful thus it's probably Ok (if worst comes to worst human can use some other means to reach the same goals). But to give the result to the Joe Average or to run stuff in production you must know how many resources it'll need in which cases.
If JVM can not be bound by a reasonable limits then it must be replaced, if Java programmer can not write code which is bound to reasonable limits then he should not be hired. It's as simple as that. "No additional memory" is often an approximation when you program in Java, sure, but that's useful approximation so why not use it?
You may showcase your deep knowleadge of Java, JVM and other related things as much as you want but if you refuse to accept simple facts of life as they apply to your work then it just means that
No Hire stamp will remain firmly in place, that all.
In a work situation, you have context -- you are normally formulating and answering these questions yourself, or if helping someone else you both have a common goal in mind.
You want to imply that said context suddenly jumps in your head when you first come to work in a new team? Nope: you need to poke around, talk with a team members, understand what goes on here, etc. And you need to balance you inquisitiveness with the fact that team members are busy (or else they will not need a new member if they have lots of spare time).
In an interview, you have no such context -- substantially more precise questions are thus called for.
Absolutely not. As everyone knows there are only two major requirements for the candidate:
2. Gets Things Done.
It's important to check that both qualities are there. And candidate who only can deal with precise, accurate and well-defined questions fails at the second part in the interview—and will probably fail similarly in the real work, too. Interview is supposed to be reproduce real work conditions in miniature. And imprecise requirements or omissions or, god forbid, even incorrect conditions are fact of life in real work so why should they be omitted in the interview? We are not looking for someone to give a honour diploma to! We are looking for someone we can use in our work!
to post comments)