--snip--
> Leandro Lucarella wrote:
>
> I know is technically right, I'm just saying it can be easily confused for something else that looks much better than the actual (very good) reality, and in this case is misleading.
>
> If you say something that's technically correct but hard to understand, you are not communicating your message effectively.

Technically correct is the best kind of correct :D

On Monday, 5 August 2013 at 17:53:48 UTC, Walter Bright wrote:
> On 8/5/2013 6:21 AM, Richard Webb wrote:
>> Is that needed, or would changing them to
>>
>>            OutBuffer->writestring(name);
>>
>> be more efficient?
>
> Yes.

https://github.com/D-Programming-Language/dmd/pull/2450

On Tuesday, 30 July 2013 at 19:05:56 UTC, Andrei Alexandrescu wrote:
> On 7/30/13 11:13 AM, Walter Bright wrote:
>> On 7/30/2013 2:59 AM, Leandro Lucarella wrote:
>>> I just want to point out that being so much people getting this wrong
>>> (and even fighting to convince other people that the wrong
>>> interpretation is right) might be an indication that the message you
>>> wanted to give in that blog is not extremely clear :)
>>
>> It never occurred to me that anyone would have any difficulty
>> understanding the notion of "speed". After all, we deal with it every
>> day when driving.
>
> And when applying the engine brake. Today, I reduced my speed by engine braking by 50%!
>
> Andrei

You deserve a trollmaster trophy for that one :D Well done !

On Wednesday, 31 July 2013 at 22:58:32 UTC, John Colvin wrote:
> On Wednesday, 31 July 2013 at 21:40:45 UTC, Bill Baxter wrote:
>> Are you serious that you can't fathom how it could be confusing to someone
>> than talking about differences in run times?
>> If you say something is faster than something else you want the two numbers
>> to be something you can relate to.  Like MPH.  Everyone has a clear concept
>> of what MPH is.  We use it every day.  So to say 25 MPH is 25% faster than
>> 20 MPH is perfectly clear.  But nobody talks about program execution speed
>> in terms of programs per second.  So I think it's pretty clear why that
>> would be harder for people to grok than changes in car speeds or run times.
>
> It's a quite impressively unbalanced education that provides understanding of memory allocation strategies, hashing and the performance pitfalls of integer division, but not something as basic as a speed.

To be fair, that is the only item of the list that involve complicated like division.

On Wednesday, 31 July 2013 at 22:58:56 UTC, Walter Bright wrote:
> On 7/31/2013 2:40 PM, Bill Baxter wrote:
>> Are you serious that you can't fathom how it could be confusing to someone than
>> talking about differences in run times?
>
> Yes.
>
> And no, I'm not talking about confusing to someone who lives in an undiscovered stone age tribe in the Amazon. I'm talking about computer programmers.
>

Considering how many programmer think javascript is near C speed, I do believe that most of them effectively do not understand the notion of speed.

On Wednesday, 31 July 2013 at 23:26:32 UTC, Walter Bright wrote:
> On 7/31/2013 3:58 PM, John Colvin wrote:
>> It's a quite impressively unbalanced education that provides understanding of
>> memory allocation strategies, hashing and the performance pitfalls of integer
>> division, but not something as basic as a speed.
>
> Have you ever seen those cards that some "electrical engineers" carry around, with the following equations on them:
>
>     V = I * R
>     R = V / I
>     I = V / R
>
> ?
>
> I found it: https://docs.google.com/drawings/d/1StlhTYjiUEljnfVtFjP1BXLbixO30DIkbw-DpaYJoA0/edit?hl=en&pli=1
>
> Unbelievable. The author of it writes:
>
> "I'm going to explain to you how to use this cheat sheet in case you've never seen this before."
>
> http://blog.ricardoarturocabral.com/2010/07/electronic-electrical-cheat-sheets.html
>
> Makes you want to cry.

Something I discovered during my studies when helping other is that most people to not even try to understand this kind of stuff. They simply brute-force the equation to their memory and regurgitate it as needed without understanding anything. Not because their aren't capable of understanding, simply because they never figured out that equation actually are saying something (and the teaching style often do not help here). They do not relate the equation to actual phenomenon they observe.

A nice example is the very basic mass times acceleration equals force.

Granted that acceleration is the variation of speed, this equation means the following :
 - If you push something it will start to move.
 - If you continue pushing it will move faster and faster.
 - If you do not push, it won't move (or continue moving the way it was).
 - The heavier it is, the harder it is to move that something.

Any child knows all the above, it is experienced it in everyday life. And the equation is simply the mathematical notation of this very basic experience.

If you don't relate such equation to anything real, you'll have all kind of trouble remembering it, knowing when to use it or how to use it.

On 8/7/2013 1:46 AM, deadalnix wrote:
>>     V = I * R
>>     R = V / I
>>     I = V / R
> If you don't relate such equation to anything real, you'll have all kind of
> trouble remembering it, knowing when to use it or how to use it.

Worse than that, they also do not understand the trivial algebraic manipulations to get the other two forms.

On 8/3/13, Walter Bright <newshound2@digitalmars.com> wrote:
> /delexe
>
>      http://www.digitalmars.com/ctg/ctgLinkSwitches.html#delexecutable

Note that this switch doesn't actually work. We've talked about this somewhere in an Optlink-related bugzilla issue.

Another little observation:

Dsymbol::toPrettyChars() potentially calls toChars() twice on each symbol (so it creates 2 copies of the string representation).
Some instances of toChars() just return a literal string, but for templates it can do a bunch of work. Doesn't sounds like the most efficient approach?


Saying that though, it looks like a lot of the calls to that are to build error strings that are never displayed because errors are gagged, which doesn't sound ideal either?

Am 12.08.2013 17:00, schrieb Richard Webb:
> Another little observation:
>
> Dsymbol::toPrettyChars() potentially calls toChars() twice on each
> symbol (so it creates 2 copies of the string representation).
> Some instances of toChars() just return a literal string, but for
> templates it can do a bunch of work. Doesn't sounds like the most
> efficient approach?
>
>
> Saying that though, it looks like a lot of the calls to that are to
> build error strings that are never displayed because errors are gagged,
> which doesn't sound ideal either?
>

i think it would be better to start a new thread for discussion optimization - its getting too deep in here :)