The devolution of English language and slothful c.l.p behaviors exposed!

[Jérôme]

Mon, 23 Jan 2012 21:57:16 -0800 (PST)
Rick Johnson a écrit:

> "Pretty" is the most ludicrous of them all! As you will see, "pretty"
> is used superfluously, over and over again! In fact, you could safely omit
> "pretty" without sacrificing any meaning of most all the sentences that
> include the word "pretty".

And so... ?

> Likewise, in 99% of the examples, the word "difficult" can be substituted
> for the word "hard" without sacrificing any meaning. 

I seriously doubt that. Did you even read the output of your grep of was that
an automatic e-mail ?

> Same for "correct" and "right".

Well... no. 

Again, read your own grep before posting it. In fact, don't post it at all.

> Of course, "used to" and "supposed to" will require people to rethink there
> lazy and slothful ways.
 
I don't even see the problem with those...

As someone already said, english is a foreign language to a lot of us. While
we're doing our best to make ourselves understood, your attitude can be seen
as quite rude. (Does "quite" fit right as a "pretty" replacement ?)

Or merely, it could. If it wasn't just ridiculous.

Now for the fun part, try to apply the substitutions you suggested on your
own grep. It is so full of false-positives it does a good job proving you
wrong.

 
> ------------------------------------------------------------
> Found 37 unique occurances of " hard " in a sentence:
> ------------------------------------------------------------
> 
> | Some general guidelines may be provided, but there is no
> | need for other "HARD" rules on breaking lines, except that
> | an identifier should never be split apart.
> |
> | 1k (and only in "HARD" copy) - this was a good 5/6 years
> | ago though.
> |
> | (but note that not all file systems support "HARD"
> | linking.
> |
> | Py <--------+ this is not a copy, it is a "HARD" link: the
> | same file appears in literally two places.
> |
> | From pylab import * x = [1,2,3,4,5,6,7,8] y = [2 for num
> | in x] #plot the parallel lines themselves in green for num
> | in range(6): y = [num for item in x]
> | plot(x,y,color='g',lw='4') #plot any conflict sections in
> | red or yellow #some "HARD" data to give the idea: x2 =
> | [3,4] y2 = [2 for num in x2] x3 = [5,6,7] y3 = [4 for num
> | in x3] x4 = [2,3] y4 = [3 for num in x4] #plot these three
> | colored parts over the green lines
> | plot(x2,y2,color='r',lw='12')
> | plot(x3,y3,color='yellow',lw='12')
> | plot(x4,y4,color='r',lw='12') pos = arange(6) yticks(pos,
> | ('net1', 'net2', 'net3', 'net4', 'net5', 'net6')) show()
> | #------------------------- che from mdickinson at
> | enthought.
> |
> | Another hack would be to add a "HARD" link to the top
> | level: as you said: "HARD" links would be a little
> | annoying on some file systems.
> |
> | Another hack would be to add a "HARD" link to the top
> | level: modules/ +-- spam.
> |
> ------------------------------------------------------------
> Found 55 unique occurances of " right " in a sentence:
> ------------------------------------------------------------
> 
> | The advantage of lambdas is that, in a list comprehension
> | or map call, the code is "RIGHT" there instead of being
> | elsewhere in a def statement.
> |
> | Poll() not in [0,1]: waiting = true so my real question
> | is: am i on the "RIGHT" track here, and am i correct in my
> | guess that the kernel is reporting different status codes
> | to subprocess.
> |
> | You can just use normal python method calls, with almost
> | every possible parameter and return value type, and pyro
> | takes care of locating the "RIGHT" object on the "RIGHT"
> | computer to execute the method.
> |
> | _test() -- terry jan reedy thank you terry, i went for
> | this solution as it was the easiest for me to understand
> | and comment myself keeping in mind what level i am at
> | "RIGHT" now.
> |
> | Getting the code "RIGHT" is going to be a lot more
> | complicated than just adding a couple of try/excepts.
> |
> | ) "RIGHT" tool for the job!
> |
> | I read "RIGHT" past that and didn't see it.
> |
> | That's not to say that one is "RIGHT" and the other is
> | wrong.
> |
> | Incidentally - this isn't really about commutativity at
> | all - the question is how can you define both left and
> | "RIGHT" versions of add, irrespective of whether they
> | yield the same result.
> |
> | If i neither disable buffering nor manually flush after
> | each print, the program just hangs instead of printing
> | "RIGHT" away.
> |
> | Having the "RIGHT" vocabulary helps.
> |
> | Log(out) i haven't tested that, but i think (from reading
> | the docs) that's the "RIGHT" idea.
> |
> | 36 is out: openopt: now solver interalg can handle all
> | types of constraints and integration problems some minor
> | improvements and code cleanup funcdesigner: interval
> | analysis now can involve min, max and 1-d monotone splines
> | r -r of 1st and 3rd order some bugfixes and improvements
> | spacefuncs: some minor changes derapproximator: some
> | improvements for obtaining derivatives in points from r^n
> | where left or "RIGHT" derivative for a variable is absent,
> | especially for stencil 1 see http://openopt.
> |
> | Am i looking in the "RIGHT" place or did they just not get
> | installed?
> |
> | __getattribute__(name) "RIGHT" thanks a lot it works
> | perfectly.
> |
> | Waiting = true so my real question is: am i on the "RIGHT"
> | track here, and am i correct in my guess that the kernel
> | is reporting different status codes to subprocess.
> |
> | I just resolved it and yes you are "RIGHT" there was a
> | (hidden) new-line to it.
> |
> | If you require a 1:1 correspondence between your code and
> | your pseudo-code specification, then maybe python isn't
> | the "RIGHT" language for this task.
> |
> | If you want to interpret it as meaning that cats are
> | yamlafiables, go "RIGHT" ahead.
> |
> | Orgon 9/11/2011 7:46 am, tigerstyle wrote: thank you
> | terry, i went for this solution as it was the easiest for
> | me to understand and comment myself keeping in mind what
> | level i am at "RIGHT" now.
> |
> | Check out the art we're digging "RIGHT" now and what's on
> | our gotta-hang-it list.
> |
> | If you really fear rogue, or malicious, scripts, perhaps
> | python is not the "RIGHT" language for this task.
> |
> | My reason for wanting to do it 'in the same script' was
> | that i also have another library that intercepts calls to
> | matplotlib's show(), so i could ultimately create a pdf
> | containing the script with figures interjected at the
> | "RIGHT" place.
> |
> | "you are right" and i am right, and you are right, and all
> | is "RIGHT" as "RIGHT" can be!
> |
> | This time, on the upper "RIGHT" corner of the rejection
> | page, i saw the following message: "your registration
> | violated our anti-spam filter.
> |
> | If | i neither disable buffering nor manually flush after
> | each print, the | program just hangs instead of printing
> | "RIGHT" away.
> |
> | I play a lot of flash games, and "RIGHT" now i'm playing
> | one that has coped poorly with a miniature slashdotting.
> |
> | The map() function is very similar to a generator
> | expression, but it can iterate over multiple iterables at
> | once: list(map(lambda x,y: x+y,[1,2,3],[40,50,60])) [41,
> | 52, 63] note how the lambda keeps the code "RIGHT" there,
> | whereas a def would separate it out.
> |
> | Yellow)        # the "RIGHT" window line((x + 60, y + 71),
> | (x + 80, y + 71), color=color.
> |
> | It is like the fortran example (just to show the syntax,
> | has an infinite loop), everyone can understand that
> | "RIGHT" away, even non fortran people: 10 loop1: do i=1,3
> | loop2: do j=1,4 print *,i,j goto 10 !
> |

There's to much of it. I'm stopping here.

Perhaps should you difficult-code some subsitution strings in your mail
client, as of correct now.

Have a nice day, guys.

---> []

-- 
Jérôme