Sorry for the short notice, but I'll be giving an introduction to D at this month's Codeaholics meetup. Drop by if you happen to be in Hong Kong!

More info here (no need for RSVP):
http://www.meetup.com/Codeaholics/events/226177740/

7pm - 9pm
CoCoon
3/F, Citicorp Centre, 18 Whitfield Road, TinHau, Hong Kong

On 11/11/2015 01:19 AM, Lionello Lunesu wrote:

>  an introduction to D at this month's Codeaholics meetup

Can you share your slides please... within the next 12 hours or so... before some of us give a similar talk... :)

Ali

On 11/11/15 18:30, Ali Çehreli wrote:
> On 11/11/2015 01:19 AM, Lionello Lunesu wrote:
>
>>  an introduction to D at this month's Codeaholics meetup
>
> Can you share your slides please... within the next 12 hours or so...
> before some of us give a similar talk... :)
>
> Ali
>

Sure thing:
https://onedrive.live.com/redir?resid=DC1E6665A482DC20%21690440

It's going to be a fairly low-level talk for a mostly python/ruby crowd, focusing on some of the key advantages of D over the others.

Will share how it's received in an hour ;)

L.

On 11/11/2015 3:03 AM, Lionello Lunesu wrote:
> Will share how it's received in an hour ;)


This is great! How did it go?

On 11/11/15 23:34, Walter Bright wrote:
> On 11/11/2015 3:03 AM, Lionello Lunesu wrote:
>> Will share how it's received in an hour ;)
>
>
> This is great! How did it go?

Actually went much better than expected! Very engaging crowd, with good questions. I think the way I positioned D was being "just another cool tool in a programmer's toolbox" really resonated with them. It certainly prevented the usual Go vs D vs Rust kind of competitiveness.

Few of the questions I got were

* Why doesn't D explicitly specify the exceptions that can be thrown? (To which I answered that I never saw the point in Java and only found it tedious. This did not convince the person.)

* Can I use D to build for ARM? (I said that the usual ARM code generators of GDC and LDC could be used, and that the runtime had less and less [if any] x86 dependencies left.)

* Why the difference between byte[] and char[]? (I explained it as being a semantic difference, with no difference in memory layout. One can be indexed meaningfully, the other can't.)

* Can I create an array of shared ints (as opposed to a shared array of ints)? I said that one could by using shared(int)[], although I have yet to try this myself.

* Does D use SIMD? (Yes, and it's leveraged automatically when you do operations on arrays.)

* How do the libraries available to D compare to the others like Go and Python? (I replied by introducing C/C++ compat and code.dlang.org)

* What if a global function with argument A has the same name as a member of A? (I talked about function hijacking and how D prevents it.)

I might remember more tomorrow. Will share if I do.

L.

On Wednesday, 11 November 2015 at 17:30:07 UTC, Lionello Lunesu wrote:
> as being a semantic difference, with no difference in memory layout. One can be indexed meaningfully, the other can't.)

Eh, indexing char[] is meaningful, you just need to know what that meaning is...

On Wednesday, 11 November 2015 at 17:30:07 UTC, Lionello Lunesu wrote:
> * Can I create an array of shared ints (as opposed to a shared array of ints)? I said that one could by using shared(int)[], although I have yet to try this myself.

Should totally work. Imagine thread-local slices from bunch of consequent int's in shared memory.

Am Thu, 12 Nov 2015 01:30:06 +0800
schrieb Lionello Lunesu <lionello@lunesu.remove.com>:

> * Why doesn't D explicitly specify the exceptions that can be thrown? (To which I answered that I never saw the point in Java and only found it tedious. This did not convince the person.)

Maybe that's your point of view or maybe you were just undecided. When you write a library it is sometimes better to be explicit about your interface and that includes any exceptions. This not only enables users of the library to selectively catch exceptions they can handle at layer X, but facilitates static checks:

* Are any exceptions missing from DDoc/@throws that are
  thrown in the code? (Potential for auto-generating the DDoc.)
* A function is nothrow, but the user only catches, e.g.
  UtfException explicitly. Is that the only exception type
  that could occur?

There were some more nice points that I don't remember from when I failed at implementing this many months ago. The questioner has my sympathy in any case, but it's certainly not a priority.

The way I wanted to implement it was by making attribute-less functions map to @throws(Exception), which implicitly makes the feature opt-in: It is always correct to state a super set of the actual thrown exceptions in an API to have room for extensions. Thrown exceptions would be collected much like nothrow is deduced right now, but as a list with respect to the hierarchical nature of Exceptions.

-- 
Marco

On 11/11/2015 9:30 AM, Lionello Lunesu wrote:
> Few of the questions I got were

These were great questions!

On 11/11/2015 9:37 AM, Adam D. Ruppe wrote:
> On Wednesday, 11 November 2015 at 17:30:07 UTC, Lionello Lunesu wrote:
>> as being a semantic difference, with no difference in memory layout. One can
>> be indexed meaningfully, the other can't.)
>
> Eh, indexing char[] is meaningful, you just need to know what that meaning is...

In C/C++, it is common to use 'char' when one is actually looking for a small integral type. 'char' in D is meant to be a UTF-8 code unit, and has semantics distinct from that of a small integral type.