Why is there no or or and ?

[F i L]

On Friday, 17 February 2012 at 17:49:53 UTC, H. S. Teoh wrote:
> On Fri, Feb 17, 2012 at 08:56:58AM +0100, F i L wrote:
> [...]
>> Thought to be honest I doubt we'll all still be designing 
>> applications
>> in text (only) editors, even fancy ones, in the next 10-15 
>> years.
>
> I know I still will be. I have never liked IDE's, and probably 
> never
> will.
>
>
>> Software design is very modular, and even arbitrary logic 
>> tools could
>> be better at presenting this data. Simple things like 
>> code-completion
>> has gone a long way flatten the learning curve, and that can 
>> only get
>> better when visual and audio logic can be manipulated in 
>> like-fashion.
> [...]
>
> True, but the initial learning curve *is* only just the initial 
> learning
> curve. Programming is essentially difficult, and whether the 
> initial
> learning curve was easy or not, sooner or later you will still 
> have to
> come to grips with the same difficult programming problems that 
> will
> require a lot of effort and ingenuity to solve.
>
> Unless you're talking about trivial things like writing GUI 
> interfaces
> and stuff like that, which require no more than the usual 
> manipulation
> of arrays and lists and simple stuff like that.
>
> Once you get past these trivial things, and get to non-trivial 
> problems
> like finding a good approximation for the travelling salesman 
> problem,
> or computing higher-dimensional convex hulls, say, you'll have 
> to think
> in the abstract anyway, so the representation really doesn't 
> matter that
> much.  Might as well stick with text-only representation so 
> that you can
> focus on the actual problem instead of being distracted by 
> pretty
> graphics.
>
>
> T

Yes, that's why i said "text (only)" because some concepts are 
simply so abstract in nature, that "writing down" the precise 
logic is the most efficient way to convey them. But typing is 
only more direct when you: 1) know the name of what you're 
looking for, and 2) The problem isn't visual, or you don't think 
visually. If you ask a person to move an object from point A to 
point B, they will visualize the movement and use their hands to 
carry it out without ever really analyzing which muscles or 
numerical angles they need for approach. Moving visual data, or 
even abstract objects like memory, around might be best 
"illustrated" to the computer by recording a more hands-on 
example and having the compiler optimize that behavior in the 
best possible way. With fine-tuning step-by-step control a 
natural, but more expert approach.

In advertising, the more positive senses (sight, sound, touch, 
etc) you can associate with a product or brand, the more you'll 
get a positive knee-jerk response to that item, because emotional 
memory is reinforced through association like any other memory. 
In good UI design, visual/audial distinction serves to associate 
controls with their function, while striving to advertise as much 
positive emotion as possible. A good example of this is GMail's 
new interface where important controls are conveyed in red and 
options are blue. So while "fancy graphics" for the sake of 
advertising alone would do nothing to boost efficiency, "fancy 
functional graphics" could help make developing software more 
direct, more conveyable, and more enjoyable overall.