Seriously?  I usually turn that feature off if I use an IDE that has it. Large projects aren't an issue. I've worked on some counted in millions of lines of code.

Sent from my iPhone

On Jan 21, 2012, at 7:23 AM, "F i L" <witte2008@gmail.com> wrote:

> Manu wrote:
>> Eg, I press '.' and the list of methods appears, and I skim through the list and choose the one that looks appropriate, I'll choose receive, and then I'll be puzzled by the argument list and why it doesn't work like I expect, after a little wasted time, I may begrudgingly read the manual... I personally feel this is an API failure, and the single most important thing that C# gets right. You can literally code C# effectively with absolutely no prior knowledge of the language just using the '.' key with code-complete in your IDE. The API's are really exceptionally intuitive.
> 
> This is a big restraint to D's popularity. It's certainly a complaint I've heard from others. An IDE with intelligence might have been a luxury in the past, but it's quickly becoming essential to large project development. Things like hunting through poorly cross-referenced documentation just to find out how to convert a string to an int, then doing it all over again when you realize the same function doesn't go both ways is just a pain in the ass.

On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org> wrote:

> I suggest checking out Erlang messaging, as it's the basis for this design. Maybe then things will be a bit clearer.


Are you suggesting that erlang is a common language that all programmers worth their paycheques are familiar with... and would also find intuitive? I don't know if it's the most sensible API decision to model a design off something so obscure, unless you suspect that D should appeal primary to ex-erlang users?

Just to re-iterate, I'm not arguing against the API or it's merits, it's really cool, just that it shouldn't be the trivial one named receive(). That name should be reserved for the most conventional API.

Seriously?  I usually turn that feature off if I use an IDE that has it.
> Large projects aren't an issue. I've worked on some counted in millions of lines of code.
>

Why even argue this? What's the point in intentionally making D unappealing
to anyone who works in a non-linux professional environment? Do you aim to
alienate those users from the community; keep the community nice and
small...
I honestly don't understand how so many people around here can blindly
consider windows users, and 'IDE users' in general, a niche or minority
user base, and also, what the value of presenting this argument might
actually be?

Who are the majority of professional devs here? What industry do they work
in? Do they, or do they intend to use D in their professional work? What
language are they coming from/using normally in their work? Do they
*really*use vi in the office?
Is there a poll, or some statistics of this sort? I'd be very curious...
because this argument comes up every other day.

Erlang being uncommon doesn't mean it doesn't have awesome features.
Java (or COBOL :p) are common, that doesn't mean we should copy them
just to make it easier for Java users to move to D.


OT, but this always pisses me off:

I use Vim. On Linux. Vim not being an IDE doesn't mean it doesn't
have autocompletion, or pretty much any common IDE feature (or... many that no IDE in existence has, for that matter). You just have
to build your own environment with plugins. I understand most people
might not want to spend time to do that, but there are quite
a few that do - and I wouldn't use anything else now, hobby or job.

(BTW, I originally used NetBeans, Eclipse, Code::Blocks on Windows - I know VS is significantly better, but nothing can tear me off
the pure productivity of my buttonless screen displaying 10 files
at once)

Oh, and don't use Vi for development (I don't know anyone who does,
anyway - for basic text editing when there's nothing else, yes, but for development?).

That said, there's no intelligent autocompletion for D in Vim (there is for C/C++, Java, Python...).
I for one would like to have it. But this is not responsibility of
DMD devs - DMD will never turn into Clang.

I hope if anyone works on a project like this, they do it as a library
so not only VisualD or DDT or whatever will benefit.


On Saturday, 21 January 2012 at 18:35:40 UTC, Manu wrote:
> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org> wrote:
>
>> I suggest checking out Erlang messaging, as it's the basis for this
>> design. Maybe then things will be a bit clearer.
>
>
> Are you suggesting that erlang is a common language that all programmers
> worth their paycheques are familiar with... and would also find intuitive?
> I don't know if it's the most sensible API decision to model a design off
> something so obscure, unless you suspect that D should appeal primary to
> ex-erlang users?
>
> Just to re-iterate, I'm not arguing against the API or it's merits, it's
> really cool, just that it shouldn't be the trivial one named receive().
> That name should be reserved for the most conventional API.
>
> Seriously?  I usually turn that feature off if I use an IDE that has it.
>> Large projects aren't an issue. I've worked on some counted in millions of
>> lines of code.
>>
>
> Why even argue this? What's the point in intentionally making D unappealing
> to anyone who works in a non-linux professional environment? Do you aim to
> alienate those users from the community; keep the community nice and
> small...
> I honestly don't understand how so many people around here can blindly
> consider windows users, and 'IDE users' in general, a niche or minority
> user base, and also, what the value of presenting this argument might
> actually be?
>
> Who are the majority of professional devs here? What industry do they work
> in? Do they, or do they intend to use D in their professional work? What
> language are they coming from/using normally in their work? Do they
> *really*use vi in the office?
> Is there a poll, or some statistics of this sort? I'd be very curious...
> because this argument comes up every other day.

On Jan 21, 2012, at 10:35 AM, Manu <turkeyman@gmail.com> wrote:

> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org>
> 
> Seriously?  I usually turn that feature off if I use an IDE that has it. Large projects aren't an issue. I've worked on some counted in millions of lines of code.
> 
> Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small...
> I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be?

I wasn't making any sort of argument, I was merely surprised at this statement.  Even most of the Java devs I know aren't this reliant on an IDE.

On 22 January 2012 02:42, Sean Kelly <sean@invisibleduck.org> wrote:

> On Jan 21, 2012, at 10:35 AM, Manu <turkeyman@gmail.com> wrote:
>
> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org>
>
> Seriously?  I usually turn that feature off if I use an IDE that has it.
>> Large projects aren't an issue. I've worked on some counted in millions of lines of code.
>>
>
> Why even argue this? What's the point in intentionally making D
> unappealing to anyone who works in a non-linux professional environment? Do
> you aim to alienate those users from the community; keep the community nice
> and small...
> I honestly don't understand how so many people around here can blindly
> consider windows users, and 'IDE users' in general, a niche or minority
> user base, and also, what the value of presenting this argument might
> actually be?
>
>
> I wasn't making any sort of argument, I was merely surprised at this statement.  Even most of the Java devs I know aren't this reliant on an IDE.
>

Most of the Java devs I know use Eclipse, and quite like the auto-compile stuff, code completion, and the reasonable quality integrated debugger. That said, most of the Java devs I know work for Google, who seem to promote use of Eclipse internally.

Regardless, I'm fairly surprised that you're surprised that there are many devs that wouldn't bother with a toolchain if it doesn't integrate with their company's workflow. For most businesses, integration with their company workflow is basic pre-requisite to consideration for adoption.

On Thu, 19 Jan 2012 23:36:12 +0100, Sean Kelly <sean@invisibleduck.org> wrote:

> Thanks :-)  If you have ideas on how it could be improved, please let me know.
>
Well you know the obvious extension, extending this to IPC, networking and user defined transport layers.
Of course we're lacking a marshalling solution for this.

ZeroMQ is probably a too heavy dependency, but it offers interesting connection schemes.

Am 22.01.2012, 01:42 Uhr, schrieb Sean Kelly <sean@invisibleduck.org>:

> On Jan 21, 2012, at 10:35 AM, Manu <turkeyman@gmail.com> wrote:
>
>> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org>
>>
>> Seriously?  I usually turn that feature off if I use an IDE that has it. Large projects aren't an issue. I've worked on some counted in millions of lines of code.
>>
>> Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small...
>> I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be?
>
> I wasn't making any sort of argument, I was merely surprised at this statement.  Even most of the Java devs I know aren't this reliant on an IDE.

I was as a Java developer reliant on an IDE. It integrates such features as SVN, refactoring, Maven2, remote debugging, powerful code completion including turning the letters "MSO" into "MySpecialObject" using camel-case matching, an embedded compiler capable of quick recompiling when you save a file, warnings while you are editing, powerful search for things like "write access to field 'x'", ... the list goes on.

On 2012-01-21 19:35, Manu wrote:
> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org
> <mailto:sean@invisibleduck.org>> wrote:
>
>     I suggest checking out Erlang messaging, as it's the basis for this
>     design. Maybe then things will be a bit clearer.
>
>
> Are you suggesting that erlang is a common language that all programmers
> worth their paycheques are familiar with... and would also find intuitive?
> I don't know if it's the most sensible API decision to model a design
> off something so obscure, unless you suspect that D should appeal
> primary to ex-erlang users?
>
> Just to re-iterate, I'm not arguing against the API or it's merits, it's
> really cool, just that it shouldn't be the trivial one named receive().
> That name should be reserved for the most conventional API.

Scala also uses a similar API as Erlang.

-- 
/Jacob Carlborg

On 22 January 2012 15:18, Jacob Carlborg <doob@me.com> wrote:

> On 2012-01-21 19:35, Manu wrote:
>
>> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org <mailto:sean@invisibleduck.org**>> wrote:
>>
>>    I suggest checking out Erlang messaging, as it's the basis for this
>>    design. Maybe then things will be a bit clearer.
>>
>>
>> Are you suggesting that erlang is a common language that all programmers
>> worth their paycheques are familiar with... and would also find intuitive?
>> I don't know if it's the most sensible API decision to model a design
>> off something so obscure, unless you suspect that D should appeal
>> primary to ex-erlang users?
>>
>> Just to re-iterate, I'm not arguing against the API or it's merits, it's really cool, just that it shouldn't be the trivial one named receive(). That name should be reserved for the most conventional API.
>>
>
> Scala also uses a similar API as Erlang.


Another super-mainstream language that everyone's familiar with :)

The popularity of a language has no bearing on the quality of one of its features. Are there other message passing schemes you prefer?

Sent from my iPhone

On Jan 22, 2012, at 5:53 AM, Manu <turkeyman@gmail.com> wrote:

> On 22 January 2012 15:18, Jacob Carlborg <doob@me.com> wrote:
> On 2012-01-21 19:35, Manu wrote:
> On 21 January 2012 18:09, Sean Kelly <sean@invisibleduck.org
> <mailto:sean@invisibleduck.org>> wrote:
> 
>    I suggest checking out Erlang messaging, as it's the basis for this
>    design. Maybe then things will be a bit clearer.
> 
> 
> Are you suggesting that erlang is a common language that all programmers
> worth their paycheques are familiar with... and would also find intuitive?
> I don't know if it's the most sensible API decision to model a design
> off something so obscure, unless you suspect that D should appeal
> primary to ex-erlang users?
> 
> Just to re-iterate, I'm not arguing against the API or it's merits, it's really cool, just that it shouldn't be the trivial one named receive(). That name should be reserved for the most conventional API.
> 
> Scala also uses a similar API as Erlang.
> 
> Another super-mainstream language that everyone's familiar with :)