Why no "cause" constructors for NumberFormatException

[Twisted]

The particular change under discussion indeed seems far more reasonable
than suggestion that all requested changes should be implemented without
even questioning their usefulness.

It was more of a question than a suggestion, but still it is also the
case that if users seriously want something, and one vendor does not
provide it, a competitor will be all too happy to ... and this is why
"the customer is always right" when it comes to product functionality.

 

[Twisted]

The users have no clue HOW the problem is best solved.

[snip rest]

This is the sort of elitism that is a rampant problem in IT these
days. The whole attitude that "the users are clueless", and the
accompanying baggage of user-hostility, tricking the users, ripping
off the users, keeping the users in the dark and fed shit according to
the mushroom theory of customer relations, patronizing and belittling
the users, ignoring the users, dedicating entire layers of
organizational structure to insulating the management from the users
from making "webmaster@" bounce to setting up an elaborate referral-
maze in the phone PBX to ensure that nobody who calls your obligatory
800 number ever actually reaches a live human being with their
complaint or feedback or request for support or information ...

I have little sympathy for IT types that show brazen disrespect for
the users, who are often the customers that ultimately pay them, and
whose needs they certainly are being paid to provide for according to
their job descriptions...

 

[Martin Gregorie]

The users have no clue HOW the problem is best solved.

[snip rest]

This is the sort of elitism that is a rampant problem in IT these
days.
>

I don't see Roedy's comment that way at all.

Is a concert goer clueless if he can't play a guitar solo?
Is a driver clueless if he can't diagnose a fuel injection fault?
Is an accountant clueless because he can't improve an SQL query?

I don't think so.

Suggesting that they are clueless is elitism, but that is twisting the
argument. Nobody was suggesting that.

OTOH suggesting that they know as much as an IT professional and hence
are equally capable of specifying a system change falls into exactly the
same trap as the post modernists when they say that because everybody's
opinion about art and other soft subjects is equally valid the same must
apply to science, engineering, etc.

 

[Patricia Shanahan]

The users have no clue HOW the problem is best solved.

[snip rest]

This is the sort of elitism that is a rampant problem in IT these
days.

I don't see Roedy's comment that way at all.

Is a concert goer clueless if he can't play a guitar solo?
Is a driver clueless if he can't diagnose a fuel injection fault?
Is an accountant clueless because he can't improve an SQL query?

I think it is very important that someone consider the cost/benefit
trade-off for any change. That can be the user, especially if the
program has a single user, but in that case they need to be informed of
the costs.

It can be the developers, but they would need to learn about the
benefits, and that is unlikely to happen if they are not allowed to ask
the users any questions about the use of a proposed feature.

Patricia

 

[Twisted]

On Jul 10, 8:25 pm, Roedy Green <[email protected]>
wrote:
The users have no clue HOW the problem is best solved.
[snip rest]
This is the sort of elitism that is a rampant problem in IT these
days.

I don't see Roedy's comment that way at all.

Is a concert goer clueless if he can't play a guitar solo?
Is a driver clueless if he can't diagnose a fuel injection fault?
Is an accountant clueless because he can't improve an SQL query?

I think it is very important that someone consider the cost/benefit
trade-off for any change. That can be the user, especially if the
program has a single user, but in that case they need to be informed of
the costs.

It can be the developers, but they would need to learn about the
benefits, and that is unlikely to happen if they are not allowed to ask
the users any questions about the use of a proposed feature.

I think I should clarify my original position. There's two things IT
professionals do that are somewhat related, only one of which is
objectionable.

One is to believe they know best about implementing the solution or
administering the system or similarly in order to enable the users to
achieve their goals. In this, they are right, assuming they are
competent to do their jobs.

The other is to believe they know better than the users what the users
should want or what the users' goals should be. This is when they are
being disrespectful to the users, and ultimately are liable to betray
the trust the users placed with them. This is unfortunately all too
common and sometimes (not always with a true and serious cause) catch
a whiff of it around here, and elsewhere on the net.

(The really, really evil ones know full well what the users' goals are
and don't *care*; these ones care about how they can interfere with
users achieving their goals in order to extort from them, or how they
can foist advertising before their eyeballs despite their wishes not
to be bothered, and suchlike. In this group we count the numerous
spammers, spyware vendors, adware crafters, devisers of DRM, and
suchlike. Bombers and cripplers of software; nagware authors; anyone
who tries to extort or annoy fees out of someone whose continued
activities don't require their services or therefore cost them any
money; anyone who distorts the architecture of a system to make the
users need services from them that they could as easily have been able
to do without, e.g. telcos that design phone systems to go through a
centralized system, thereby costing the telcos when used, thereby
granting the telcos a reason to charge money for every minute of call
time, specifically designing them to be incapable of routing calls
through an ad-hoc network simply because this would give the users
more and cost less, so they would not be able to charge very much
money at all. This last is a crime against efficiency and, in these
days of climate disturbance and dwindling oil supplies, that makes it
quite simply a crime. Ad-hoc-capable phones would have saved thousands
in New Orleans which compounds the telcos' crime in deliberately
crippling the cellular telephone technology's potential to maximize
their own revenues. Of course, the cellular oligopoly is seeing
upstart competition now from new kinds of wireless tools, with the
likelihood that it will soon prove that their design decisions were
also criminal with respect to their long-term fiduciary obligations to
their stockholders on top of everything else...

IT types that deliberately stand athwart user goals for reasons of
greed I liken to the old tales of trolls under bridges. Either they
didn't build the bridge at all, or the costs of construction were long
since paid and the maintenance costs are minimal, yet they insist on
extorting a fat toll from every traveler to cross. With any kind of
pay software we can observe the nearby "open source" bridge, whose
builders toiled without recompense to construct it, then set up shop
near the bridge knowing to benefit from all the traffic as merchants,
and end up making plenty of money and earning far more goodwill from
travelers besides. From time to time they maintain their bridge out of
a fraction of their revenues as merchants, knowing its collapse would
end their profitability. Then the trolls appear not only greedy but
foolish and lacking in business sense besides.)

 

[Oliver Wong]

Twisted wrote:
On Jul 10, 8:25 pm, Roedy Green <[email protected]>
wrote:
The users have no clue HOW the problem is best solved. [...]
This is the sort of elitism that is a rampant problem in IT these
days.

[...]
I think I should clarify my original position. There's two things IT
professionals do that are somewhat related, only one of which is
objectionable.

One is to believe they know best about implementing the solution or
administering the system or similarly in order to enable the users to
achieve their goals. In this, they are right, assuming they are
competent to do their jobs.

The other is to believe they know better than the users what the users
should want or what the users' goals should be. This is when they are
being disrespectful to the users, and ultimately are liable to betray
the trust the users placed with them. This is unfortunately all too
common and sometimes (not always with a true and serious cause) catch
a whiff of it around here, and elsewhere on the net.

I think there's another relevant thing that IT people do: believe that
sometimes client is unable to express what they want.

There's a lot of absolutes being thrown about in this thread, so I'd
like to address that before coming back to my main point. *USUALLY* the IT
person in charge of a given IT project knows more about computers than the
client paying for the project. Usually. Not always. Usually the IT person
knows more about programming than the client; but not always. Usually the
IT person knows more about software design than the client; but not
always.

Sometimes, the client is a really smart
programmer/software-architect/engineer/whatever who just happens to be
hiring someone to do an IT project for them, and the person they are
hiring is less skilled than they are. It could simply be that the client
has more important projects to take care of, and just needs some bodies to
finish off the easy parts of a nearly complete project. Here, the client
knows more about computers/programming/etc. than the programmer.

For the rest of this post, I'm going to be talking about the more
common case where the client is someone who knows very little about
computers, and just wants to throw money at someone who'll take care of
all the details, as long as they get what they want.

But again, sometimes the client is unable to express what they want.
And sometimes one of the IT people has, as a primary function, to extract
from the client exactly what it is that they want specifically because
clients have so much trouble expressing what they want.

Let's say the client, familiar with math, statistics, game design,
literature, etc. but not very familiar with computer science, says "I want
to make a game, and as a first step I want a random number generator that
will give me a uniform distribution of all possible values between 0 and
1". Well, the client is almost surely mistaken. The vast majority of
numbers between 0 and 1 are uncomputable (that is, they have an
Kolmogorov-Chaitin complexity of infinity, and cannot possibly be
generated by a Turing Machine). Much more probably, what the client
"really" wants is for all IEEE double values between 0 and 1 being
generated with equal probability.

So now, the IT person, who has been sent as a liaison/interpreter
between the clients and the programming team, has a choice of what to do.
Do they tell the client that their request as stated is impossible to
satisfy, lecture them about the size of the set of integers and reals,
IEEE standards, Turing Completeness and so on, or do they just assume they
know better than the user what they really want, and jot down "Random
Number Generator, 0.0 <-> 1.0" on their task list, and move on to the next
set of requirements?

Again, there's a bit of context involved: If the client's project has
something to do with encryption or online gambling or stuff like that,
then you might need to probe the for more details, such as whether a
"truly random" generator is required (and you might get into philosophical
debates about the definition of "truly random"), or if whether Java's
built in pseudo-random number generator is "good enough". But if they're
just making a single player game, you can generally assume that a PRNG is
what the client really wants.

A part of "doing what the customer wants" is usually "don't bug the
client too much with the details". If the client knew all the details of
how to do what they wanted to do, they'd probably just do it themselves
(with the exceptions mentioned above).

Clients (and people in general) also tend not to be very good at
judging what parts of their request require a lot of detail, and what
parts are best left up to the whims of the developers.

The end goal of everybody is to become happier. If you tell a software
developer to write software that will make the client happy, the software
developer is probably going to complain that the request is too vague, and
outside of the dev's area of expertise. The client needs to do some
analysis of their own to determine (perhaps correctly, perhaps
incorrectly) that being rich will make them happy, that having more
profits and fewer expenses will make them rich, and that it must be
possible software will increase profits and reduce expenses. Now we're
getting closer to the point where a software dev can come in handy.

At the other extreme, the client may give requirements that are overly
specific, that they don't really care about, and that make the developer's
life more difficult, simply because they felt that they should give lots
of specific details (perhaps because in the past, they had received
complaints that their requirements were too vague).

As an example of this, a client may state that they want an HTML
document to be generated which has very specific formatting requirements
when printed; for example, with a specific footer appearing on the first
page, and a different footer appearing at the bottom of every other page.

In theory, this is possible: We could try develop some sort of spyware
which would secretly get executed on the end user's computer, accurately
detect the browser and OS being used (can't trust the agent-string sent
in), and the size of the paper in the printer's tray, and force-configure
the printer margins to be a specific setting (e.g. 0.3 inches), and then
use lots of <div> tags and CSS hacks to exactly position elements on a
pixel-by-pixel basis. We'd have to generate different HTML and CSS
combinations for every OS, browser and paper size combination (and there
are over 500 versions of Firefox for Windows alone, so this is quite an
explosive combinatorics equation). If we're going to be installing spyware
on the user's computer, why don't we just have the spyware directly
communicate with the printer, you ask? Well, the user *said* they wanted
an HTML document generated, and for that HTML document to get printed.

Instead, we asked them if we could just generate the document as PDF
instead of HTML. It turns out that we could, and the client didn't really
care either way. Made our lives a lot easier.

- Oliver

 

[Twisted]

So now, the IT person, who has been sent as a liaison/interpreter
between the clients and the programming team, has a choice of what to do.
Do they tell the client that their request as stated is impossible to
satisfy, lecture them about the size of the set of integers and reals,
IEEE standards, Turing Completeness and so on, or do they just assume they
know better than the user what they really want, and jot down "Random
Number Generator, 0.0 <-> 1.0" on their task list, and move on to the next
set of requirements?

This doesn't bug me. There's nothing arrogant or condescending
involved here; just interpretation that seems reasonable.

Again, there's a bit of context involved: If the client's project has
something to do with encryption or online gambling or stuff like that,
then you might need to probe the for more details, such as whether a
"truly random" generator is required (and you might get into philosophical
debates about the definition of "truly random"), or if whether Java's
built in pseudo-random number generator is "good enough". But if they're
just making a single player game, you can generally assume that a PRNG is
what the client really wants.

Terrible idea. Java's built in PRNG is an LCG, which isn't simulation
grade. Too high correlations between random N and random N+K for some
small choices of K. If you want a PRNG in a game you want Mersenne
Twister, which is fairly fast and efficient and is simulation
grade.

It does make sense to ask the client if they want repeatability and if
they want a cryptographically secure one. Repeatability requirements
rule out using hardware noise or "entropy pool" RNGs. Cryptographic
grade suggests using Java's SecureRandom, or using an LCG to discard
random numbers of sequential results from another LCG, both with long
repeat times and large prime ratios involved. (This prevents exposing
the N+K correlation in e.g. session keys, ID numbers, or other exposed
data which otherwise might allow someone to guess the next number
after seeing a few and crack or spoof something. SecureRandom might
already work this way, or it might be a more complex scheme; I don't
know much about its internals.) So there may certainly be cases where
you need to get requirement information from the client. They might
not really know whether they need simulation-grade or secure or some
such random numbers. I'd ask them a bit about the game. If it's a
shoot-em-up MT is probably best. If it's online poker, with fewer
randoms needed but money riding on those randoms being unguessable in
advance, I'd use a cryptographic-grade RNG even if it meant it was
slower. If repeatability wasn't needed but unguessability was crucial,
I might use an entropy pool or a hardware RNG -- a stand-alone poker
terminal could include a hardware RNG; PC software probably can't; an
online poker server can get entropy pool effects by sharing a single
good and fast RNG among all connected sessions, so you could not guess
the next shuffle at any one virtual table without monitoring ALL the
virtual tables, but the RNG has to be damned fast in this case, and
the server should preshuffle the next few virtual decks concurrently
(though thread-safely) to ensure the RNG state is thoroughly mixed
with all of those shuffles, then use those decks when fresh shuffled
decks are needed by a connected session, keeping a queue of shuffled
virtual decks to use. This implies a backend service that acts as a
shuffled-deck factory, possibly on fast dedicated hardware in the
poker company's back office. This might even have added physical
security and access restrictions, depending on the stakes involved.
(And the backend has to validate cards somehow in this case, or the
deck can be tampered with undetectably after it leaves the black box.
The other major way to cheat, peeking at someone else's cards, needs
wholly different sorts of security to defeat, such as cryptography on
client connections. Stopping players from "teaming up" in online poker
and consensually sharing information through back-channels is probably
not even feasible.)

Of course, a high-stakes online poker company should probably invest
in some in-house security expertise of its own to make recommendations
about implementation of sensitive parts of the system!