On Monday, 7 September 2015 at 13:41:31 UTC, Jacob Carlborg wrote:
> On 2015-09-06 15:24, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
>
>> Oh, actually it appears to run on both OS-X and Linux. I didn't know
>> that. Looks very promising, thanks!
>
> Yeah, it's built on the same framework as Atom. Or were you hoping for Visual Studio, sans Code, on OS X and Linux?

I knew there was an Atom based type script editor (or several?), but didn't know that Microsoft was behind it and that "VS Code" was different from "VS"/"VS Express" ;).

Typescript seems to have a lot of momentum. I'm thinking about the possibility of a transpiler TypeScript->D (and other languages).

On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
> Martin ran some benchmarks recently that showed that ddmd compiled with dmd was about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical.
>
> I'm interested in ways to reduce that gap.
>
> There are 3 broad kinds of optimizations that compilers do:
>
> 1. source translations like rewriting x*2 into x<<1, and function inlining
>
> 2. instruction selection patterns like should one generate:
>
>     SETC AL
>     MOVZ EAX,AL
>
> or:
>     SBB EAX
>     NEG EAX
>
> 3. data flow analysis optimizations like constant propagation, dead code elimination, register allocation, loop invariants, etc.
>
> Modern compilers (including dmd) do all three.
>
> So if you're comparing code generated by dmd/gdc/ldc, and notice something that dmd could do better at (1, 2 or 3), please let me know. Often this sort of thing is low hanging fruit that is fairly easily inserted into the back end.
>
> For example, recently I improved the usage of the SETcc instructions.
>
> https://github.com/D-Programming-Language/dmd/pull/4901
> https://github.com/D-Programming-Language/dmd/pull/4904
>
> A while back I improved usage of BT instructions, the way switch statements were implemented, and fixed integer divide by a constant with multiply by its reciprocal.

Maybe the ENTER instruction should be replaced by a full prologue:

- https://github.com/D-Programming-Language/dmd/blob/ef24f9acd99aa52ed28e7221cb0997099ab85f4a/src/backend/cod3.c#L2939
- http://stackoverflow.com/questions/5959890/enter-vs-push-ebp-mov-ebp-esp-sub-esp-imm-and-leave-vs-mov-esp-ebp

It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER.

On Sunday, 13 September 2015 at 17:30:12 UTC, BBasile wrote:
>
> It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER.

Same here, I thought nobody used this one instruction.

On 09/13/2015 07:30 PM, BBasile wrote:
> It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER.

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

On Sunday, 13 September 2015 at 18:33:52 UTC, Martin Nowak wrote:
> On 09/13/2015 07:30 PM, BBasile wrote:
>> It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER.
>
> https://github.com/D-Programming-Language/dmd/pull/5073

Yeah, that was fast. With the hope it'll be approved.

On 09/13/2015 08:45 PM, BBasile wrote:
> Yeah, that was fast. With the hope it'll be approved.

If only it wasn't for me to do this...

On 28/08/2015 22:59, Walter Bright wrote:
> People told me I couldn't write a C compiler, then told me I couldn't
> write a C++ compiler. I'm still the only person who has ever implemented
> a complete C++ compiler (C++98). Then they all (100%) laughed at me for
> starting D, saying nobody would ever use it.
>
> My whole career is built on stepping over people who told me I couldn't
> do anything and wouldn't amount to anything.

So your whole career is fundamentally based not on bringing value to the software world, but rather merely proving people wrong? That amounts to living your professional life in thrall of other people's validation, and it's not commendable at all. It's a waste of your potential.

It is only worthwhile to prove people wrong when it brings you a considerable amount of either monetary resources or clout - and more so than you would have got doing something else with your time.

It's not clear to me that was always the case throughout your career... was it?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 02/09/2015 19:58, Walter Bright wrote:
> On 8/29/2015 12:37 PM, Laeeth Isharc wrote:
>> In my experience you can deliver
>> everything people say they want, and then find it isn't that at all.
>
> That's so true. My favorite anecdote on that was back in the 1990's. A
> friend of mine said that what he and the world really needs was a Java
> native compiler. It'd be worth a fortune!
>
> I told him that I had that idea a while back, and had implemented one
> for Symantec. I could get him a copy that day.
>
> He changed the subject.
>
> I have many, many similar stories.
>
> I also have many complementary stories - implementing things that people
> laugh at me for doing, that turn out to be crucial. We can start with
> the laundry list of D features that C++ is rushing to adopt :-)
>

Yes, and this I think is demonstrative of a very important consideration: if someone says they want X (and they are not paying upfront for it), then it is crucial for *you* to be able to figure out if that person or group actually wants X or not.

If someone spends time building a product or feature that turns out people don't want... the failure is on that someone.


And on this aspect I think the development of D does very poorly. Often people clamored for a feature or change (whether people in the D community, or the C++ one), and Walter you went ahead and did it, regardless of whether it will actually increase D usage in the long run. You are prone to this, given your nature to please people who ask for things, or to prove people wrong (as you yourself admitted).

I apologize for not remembering any example at the moment, but I know there was quite a few, especially many years back. It usually went like this:

C++ community guy: "D is crap, it's not gonna be used without X"
*some time later*
Walter: "Ok, I've now implemented X in D!"
the same C++ community guy: either finds another feature or change to complain about (repeat), or goes silent, or goes "meh, D is still not good"
Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"...


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros wrote:
> Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"...

D is fun for prototyping ideas, so yes half-baked and not stable, but still useful.

I'm waiting for Rust to head down the same lane of adding features and obfuscating the syntax (and their starting point is even more complex than D's was)...

On 9/16/2015 7:16 AM, Bruno Medeiros wrote:
> On 28/08/2015 22:59, Walter Bright wrote:
>> People told me I couldn't write a C compiler, then told me I couldn't
>> write a C++ compiler. I'm still the only person who has ever implemented
>> a complete C++ compiler (C++98). Then they all (100%) laughed at me for
>> starting D, saying nobody would ever use it.
>>
>> My whole career is built on stepping over people who told me I couldn't
>> do anything and wouldn't amount to anything.
>
> So your whole career is fundamentally based not on bringing value to the
> software world, but rather merely proving people wrong? That amounts to living
> your professional life in thrall of other people's validation, and it's not
> commendable at all. It's a waste of your potential.
>
> It is only worthwhile to prove people wrong when it brings you a considerable
> amount of either monetary resources or clout - and more so than you would have
> got doing something else with your time.
>
> It's not clear to me that was always the case throughout your career... was it?

Wow, such an interpretation never occurred to me. I will reiterate that I worked on things that I believed had value and nobody else did. I.e. I did not need validation from others.