The Revenge of the Geeks

[Arne Vajhøj]

well, this is where the whole "mandatory interop or orders from above"
comes in. in such a case, people say what to do, and the programmer is
expected to do so.

but, I more meant for cases where a person has free say in the matter.

and, also, a person still may choose an existing option, even if bad,
because it is the least effort, or because it is still locally the best
solution.

like, rolling ones' own is not required, nor necessarily always the best
option, but can't necessarily be summarily excluded simply for sake of
"standards", as doing so may ultimately just make things worse overall.

It almost can.

If you go non standard and problems arise, then you are in
deep shit.

Arne

 

[Arne Vajhøj]

On 01/26/2013 04:47 PM, BGB wrote:
On 1/26/2013 8:12 AM, Arne Vajhøj wrote:
On 1/26/2013 12:31 AM, BGB wrote:

[snip]


people are not too happy about HTTP and SMTP either.

huh ... what's wrong with HTTP ???

Read about the reasons behind the HTTP 2.0 effort.

Nobody could possibly have imagined that HTTP would
become such an important protocol.

True.

But that just explains why we have the problems.

It does not help solve the problems.

If people are unhappy about HTTP it's because they are trying to force
the protocol to do things it was never designed to do. The fact that it
*is* so flexible and extensible is surely testament to one mans vision
and humanities ingenuity in general.

Almost everybody is forcing stuff on HTTP that it was not intended for
these days.

I know we don't see eye to eye about many things Arne but that has to be
one of your more absurd statements.

IETF, Google and Microsofts does not seem to think it is absurd
since they are working to solve the problems.

Arne

 

[Arne Vajhøj]

On 1/26/2013 8:47 PM, Arved Sandstrom wrote:
On 01/26/2013 04:47 PM, BGB wrote:
On 1/26/2013 8:12 AM, Arne Vajhøj wrote:
On 1/26/2013 12:31 AM, BGB wrote:
[snip]


people are not too happy about HTTP and SMTP either.

huh ... what's wrong with HTTP ???

Nobody could possibly have imagined that HTTP would
become such an important protocol.

If people are unhappy about HTTP it's because they are trying to force
the protocol to do things it was never designed to do. The fact that it
*is* so flexible and extensible is surely testament to one mans vision
and humanities ingenuity in general.

I know we don't see eye to eye about many things Arne but that has to be
one of your more absurd statements.

I wonder how many contributors to this list would be making a (good)
living out of 'IT' if HTTP and the World Wide Web had never been
invented.

probably the main issue is that it involves opening a connection for a
single request/response pair, and doesn't (generally) allow reusing the
socket for multiple requests (as-in, not without ugly hacks).

keep-alive has been used for many years.

But it is certainly not without its problems.

to some extent, this has lead to the development of technologies like
HTTP 2.0 / SPDY, and WebSockets, partly to better address some of these
use-cases.

Yep.

Arne

 

[BGB]

As long as you don't try and shoehorn the different languages
into the same paradigm then that should not be a problem.

yeah.

different languages do different things.

 

[BGB]

It almost can.

If you go non standard and problems arise, then you are in
deep shit.

depends on costs...

if "liability" is involved, or the functioning of the software is
"mission critical" or something, then there is more reason for concern.


for many types of apps though, hardly anyone gives a crap how any of it
works internally anyways, and people can pretty much do whatever.

(like, if it crashes or breaks violently, oh well, the user will start
it up again, and at worst probably the user will think less of the
product if it is too much of a buggy piece of crap, ...).

granted, this is generally a reason to test things, like to verify that
they basically work, and try to debug cases where things are prone to
crash or otherwise go terribly wrong, ...

 

[Roedy Green]

but then how would the download sites make money, if they can't make
every banner be a giant green "Download" button, with the actual
download for the program being a little plain-text link somewhere near
the bottom of the page somewhere?...

ain't it the truth.

I was so naive, that not long ago I would write webmasters warning
them of the confusion they had created with "misplaced" unlabeled
download buttons.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

depends on costs...

if "liability" is involved, or the functioning of the software is
"mission critical" or something, then there is more reason for concern.


for many types of apps though, hardly anyone gives a crap how any of it
works internally anyways, and people can pretty much do whatever.

(like, if it crashes or breaks violently, oh well, the user will start
it up again, and at worst probably the user will think less of the
product if it is too much of a buggy piece of crap, ...).

Not everything is important.

But best practices should be based on an assumption about it
being important.

Arne

 

[BGB]

Not everything is important.

But best practices should be based on an assumption about it
being important.

could be, or it could be that the importance of the system is another
factor to be weighed in considering design choices (along with other
design-quality concerns, concerns over what other people will think, of
possible consequences, ...).

like, if the importance is high, then choosing the most well proven
technologies is best, and if fairly low, then it may mostly boil down to
"whatever works".

sometimes a person may be working more towards the most "elegant"
solution, regarding whether or not it actually works, as a secondary
concern (say, their whole premise is basically to write it, so that they
can write a research paper about it).

....


so, a lot is about balancing relevant factors, because while being well
proven and standard technology is one thing, other factors, like
development time, and how well it holds up against the offerings by
ones' competitors, or how much end-user appeal there is, as well as
potentially the computational performance, ... may also be factors.


granted, in general, I guess I tend to go under the premise of "there
should not be should", though there are exceptions to this, usually in
cases where there is a significant potential impact on product quality,
safety, or if there are potential legal, ethical, or moral, consequences.

so, yeah, while freedom of choice is important, it also seems to be the
case that a person should try to do the right thing.

which in the case of a product, would mostly boil down to potential
impacts to the quality of life or quality of experience to the end-users
of a product (like, it is better not to rip people off of put their
personal health or safety at risk, ...).


but, it all depends a lot on the product.

(like, if the product is actually in a position to pose a risk, ...).


like, it is hard to find universal rules that would apply equally well
to every sort of software.


it is even like answering the question of which is better between float
and double. and, meanwhile, some people think double isn't precise
enough, leading to 128-bit floats, and others think a 32-bit float isn't
cheap enough, leading to 16-bit half-floats.

and, while both 128-bit and 16-bit floats are useful, what sorts of
things they are useful for are very different (like, for example, if a
person needs more than about 3 decimal digits of precision, ...).


or such...

 

[Stuart]

We may be a bit old fashioned in the Java group.

Facts is still considered a positive.

When I first saw this sub-thread, I was hoping that this following
conversation only consisted of references to Dilbert comic strips. That
would have been a quite unique and probably avantgardistic form of
communication.

A chance forfeited ...

Stuart

 

[Arne Vajhøj]

could be, or it could be that the importance of the system is another
factor to be weighed in considering design choices (along with other
design-quality concerns, concerns over what other people will think, of
possible consequences, ...).

like, if the importance is high, then choosing the most well proven
technologies is best, and if fairly low, then it may mostly boil down to
"whatever works".

Not really.

Unless there really is an advantage of going with the non-standard
solution, then you would go for standard even for the less important
stuff.

so, a lot is about balancing relevant factors, because while being well
proven and standard technology is one thing, other factors, like
development time, and how well it holds up against the offerings by
ones' competitors, or how much end-user appeal there is, as well as
potentially the computational performance, ... may also be factors.

They can.

But the home-made solutions often promise to be better but rarely
delivers.

Arne

 

[BGB]

Not really.

Unless there really is an advantage of going with the non-standard
solution, then you would go for standard even for the less important
stuff.

usually, there are advantages in edge-cases.

in cases where a standard technology exists which does the job fairly
well, then it usually makes most sense to use it.

for example, PNG and JPEG are pretty good, so there are few reasons not
to use them (for most things image-storage related).

like, not being chained to standards, does not mean making a standard of
non-standard either.



where it makes more sense to ignore the standardized technologies is
when they either aren't very good, or are notably bad (and actually
using them would likely leave the product worse off).

it is like, trying to take VRML seriously as a 3D model format.

VRML is standardized, but the W3C at the time seemingly managed to get
nearly everything wrong in the design. then later, they tried again with
X3D, which sort of competes against COLLADA, which AFAICT is much more
popular (despite X3D being shoved into a larger number of other
standards, like HTML5 and MPEG-4...).


likewise for the OSI protocols, ... people were largely just like
"whatever" and continued using TCP/IP (IETF largely won this battle).


nevermind if, officially (as per the standards), JPEG was replaced by
JPEG-2000 around 13 years ago, and more recently there is JPEG-XR.

meanwhile, the original JPEG remains the more well-supported format by
most software (much easier to find apps which read/write JPEG images
than JP2 or JXR images).

....


sometimes, using a standard technology may actually make things worse
off in other ways.

for example, it is popular at present for people to make various file
formats consisting of XML documents or similar packaged up into a
ZIP-based container.

while this is easier to approve as "open" or "standard", it comes with a
drawback:
some applications are prone to detect the ZIP-related magic values, and
automatically change the file extension to ZIP, which can sometimes
prove rather annoying (whereas, if a non-ZIP container format were used,
these tools would more often leave the file alone).

it also makes little sense if the intention is actually for the
application to keep the data to itself, such as for a proprietary
file-format, where it may actually be to ones advantage if unaware
parties (such as competitors, ...) have little idea what the file contains.

They can.

But the home-made solutions often promise to be better but rarely
delivers.

I have generally been having generally good results with various
custom-designed technologies.


but, this again comes back to cost/benefit tradeoffs:
if the results of the choice don't pay off well, it means they did not
make a good choice, not that having had an option to make choice was to
blame.

like, having the freedom to make a choice does not mean freedom from any
consequences of having made the choice.

like, having freedom to make choices also means the freedom to shoot
oneself in the foot.


sometimes, a simple direct solution can also be better than a bigger
"standard" solution, for example:
passing simple lists or arrays for internal messages, vs using DOM or
similar;
using a HashMap or similar, vs using an RDBMS, to store key/value pairs
or similar;
passing plain data, rather than using RPC or similar;
....

like, a possible premise:
don't use a sledgehammer to do what can easily enough be done with a
tack-hammer.

like, even if the standard solution is to store data in a DBMS, the
HashMap may be simpler, easier, and also potentially significantly
faster, ...



BTW: have been, mostly for the hell of it, in the process of porting my
stuff to be able to work on Native Client. most of the work thus far is
in trying to migrate the stupid 3D renderer from the full OpenGL to
OpenGL ES.

to make this work, I am as well having to make a "hand-made solution":
namely, migrating much of the code from using normal OpenGL calls to
using a set of wrapper functions (which will then fake things and pass
the results off to GLES). (too much of the code still relies on the
existence of the "fixed function pipeline", so for GLES it needs to all
be faked...).

I guess the more standard solution here would be to rewrite all the code
directly (rather than forcing it onto wrappers), but this would be more
work.


but, then again, it is notably easier in this case to go with a
non-standard technology (Native Client), even if largely tied to a
single browser, than to go with a more standardized technology (IOW:
trying to rewrite a 3D engine into HTML5+JS+WebGL to shove it into a
browser).

granted, for targeting a browser up-front (writing a new engine
ground-up or similar), the HTML5+JS+WebGL route could probably make more
sense (at least assuming "general" things, like that the browsers are
smart enough to know how to cache compiled code and similar...).

 

[Arne Vajhøj]

usually, there are advantages in edge-cases.

It certainly happens.

I have generally been having generally good results with various
custom-designed technologies.

By the judgement of the author or by the judgement of
neutral judges??

Arne

 

[Gene Wirchenko]

[snip]

By the judgement of the author or by the judgement of
neutral judges??

Who cares about neutral judges? How about someone with some skin
in?

I maintain an in-house client billing app that has a form for
handling invoicing. There are 34 buttons for various general
functions that one might want to do and for each work order being
presented, there are two or three (depends on circumstances) more
buttons. This is the sort of design that could get submitted to the
Interface Hall of Shame.

However, and this is a big however, it makes invoicing fairly
easy. The owner of the company suggested the general approach. I
made it work. He uses it for invoicing, and when I was working Down
There, I was doing invoicing with it as well. It works and works
well.

But a neutral judge might choke on the buttons.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

[snip]

By the judgement of the author or by the judgement of
neutral judges??

Who cares about neutral judges? How about someone with some skin
in?

I maintain an in-house client billing app that has a form for
handling invoicing. There are 34 buttons for various general
functions that one might want to do and for each work order being
presented, there are two or three (depends on circumstances) more
buttons. This is the sort of design that could get submitted to the
Interface Hall of Shame.

However, and this is a big however, it makes invoicing fairly
easy. The owner of the company suggested the general approach. I
made it work. He uses it for invoicing, and when I was working Down
There, I was doing invoicing with it as well. It works and works
well.

But a neutral judge might choke on the buttons.

I doubt it. Good UX is different for different types
of people. People that use an app a lot is known to prefer
to have as much functionality as possible directly
accessible without going through too much hassle.

And anyway it is not really your idea, so you do not risk
your judgement to be influenced by owners pride. The owner
may be a poor judge as it is his baby.

Arne

 

[BGB]

[snip]

By the judgement of the author or by the judgement of
neutral judges??

Who cares about neutral judges? How about someone with some skin
in?

I maintain an in-house client billing app that has a form for
handling invoicing. There are 34 buttons for various general
functions that one might want to do and for each work order being
presented, there are two or three (depends on circumstances) more
buttons. This is the sort of design that could get submitted to the
Interface Hall of Shame.

However, and this is a big however, it makes invoicing fairly
easy. The owner of the company suggested the general approach. I
made it work. He uses it for invoicing, and when I was working Down
There, I was doing invoicing with it as well. It works and works
well.

But a neutral judge might choke on the buttons.

I doubt it. Good UX is different for different types
of people. People that use an app a lot is known to prefer
to have as much functionality as possible directly
accessible without going through too much hassle.

could be.

I generally prefer keyboard shortcuts for a lot of things, and in
general am not a fan of "wall of buttons" style GUIs, but don't really
exactly think keyboard shortcuts are any one-true-user-input either.

And anyway it is not really your idea, so you do not risk
your judgement to be influenced by owners pride. The owner
may be a poor judge as it is his baby.

yeah, I am the user of a lot of my own stuff, so can't really be called
a neutral-observer here here, and generally felt it pointless to try to
argue over whether or not I can judge myself objectively... dealt with
this problem enough even trying to resolve something as simple as
personality type... (though on this one I did eventually settle on ISTP
as probably most-likely-correct, despite so often coming off so much
like an INTx...).

but, yeah, I can claim to have good luck with my stuff, and whether or
not other people think it is all crap, oh well, either way...


as for determining whether or not a person is acting in accordance with
their own best interests is, however, a similarly difficult problem, as
is determining exactly what ones' best interests actually *are* (like,
with the potential of inefficiency and opportunity cost and so on,
leading to the issue that even a generally effective course of action
may not necessarily be optimal).

it seems that a person either ends up with potentially mutually
contradictory conclusions (where the "self-interest value" becomes
context-dependent), or has to deal with the ugly issue of (often
arbitrary) "intrinsic properties", and the issue that there is no good
way to validate whether "intrinsic worth" actually has worth, and if a
person defines it in terms of self-benefit (or some other similar
metric), they are right back where they started. (stupid philosophical
logic circles...).


easier just to be like "well, it works for me".

it is generally much more effective IME to argue about things that can
be tested and measured.


elsewhere, I managed to get into an argument with people between storing
images in PNG and JPEG, vs using DDS.

I personally prefer PNG and JPEG...

some people insisted though that DDS was essentially the "one true
graphics format" and that PNG and JPEG and similar are essentially
"legacy formats".

I disagreed...


there are plenty of reasons to prefer something like PNG or JPEG over
something like DDS or BMP or similar.

and, there are measurable reasons to prefer something like PNG or JPEG
over DDS or BMP as well, ...

well, and there is always WDP / JXR (HD Photo / JPEG-XR)...


but, alas...

 

[Gene Wirchenko]

On 2/4/2013 5:09 PM, Gene Wirchenko wrote:
[snip]

But a neutral judge might choke on the buttons.

I doubt it. Good UX is different for different types

Sorry. I have had too much exposure to people dissing things
that are not the way that they would do it.

of people. People that use an app a lot is known to prefer
to have as much functionality as possible directly
accessible without going through too much hassle.

Last sentence: I had not thought of that exactly that way, but
yes, I think you nailed it there. Thank you for the insight.

And anyway it is not really your idea, so you do not risk
your judgement to be influenced by owners pride. The owner
may be a poor judge as it is his baby.

If I go along with a bad idea in my area, I am culpable. I do
not have a problem with the design though. I thought at first that it
looked a bit odd, but my first priority is does it work? It works
well. And remember that I know that since I have used it to do real
work.

Sincerely,

Gene Wirchenko