On 2/1/15 1:03 PM, uri wrote:
> int[$] a=[1,2,3];
>
> The syntax sugar helps when prototyping ideas, which is why R and Octave
> (MATLAB) are so useful.

Do R, Octave, or Matlab have the ability to define arrays on the stack? -- Andrei

On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:
> On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:
>
>> Propensity for bike-shedding behind the covers of intellectual
>> refinement puzzles me.
>
> this is part of "be smart!" strategy. anyone who is not smart enough
> doesn't deserve the right to use D. and "being smart" means "manually do
> the work that compiler can automate".

It would help if dynamic-array/slice/fixed-size-array and value/reference/ownership types had been well designed from the get go.

Inconsistencies in syntax and special casing the typing requires the user to "be smart", because the language is "dumb". But making the compiler smarter to fix a dumb language is the wrong path. The right thing to do is to redesign what is "dumb" (the language).

On Sunday, 1 February 2015 at 23:19:53 UTC, Andrei Alexandrescu wrote:
> On 2/1/15 1:03 PM, uri wrote:
>> int[$] a=[1,2,3];
>>
>> The syntax sugar helps when prototyping ideas, which is why R and Octave
>> (MATLAB) are so useful.
>
> Do R, Octave, or Matlab have the ability to define arrays on the stack? -- Andrei

No they don't, at least not to my knowledge and we use Matlab every day at my workplace.

I think what Uri is referring to is the very low resistance once sees in the syntax of R, Matlab, Python when going from an idea or algorithm on paper to code.

I've always found dynamic arrays in D are perfectly fine for rapid prototyping code, however, my situation may be different from that Uri.


Cheers,
stew

On Mon, 02 Feb 2015 00:00:00 +0000, Ola Fosheim Grøstad wrote:

> On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:
>> On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:
>>
>>> Propensity for bike-shedding behind the covers of intellectual refinement puzzles me.
>>
>> this is part of "be smart!" strategy. anyone who is not smart enough doesn't deserve the right to use D. and "being smart" means "manually do the work that compiler can automate".
> 
> It would help if dynamic-array/slice/fixed-size-array and value/reference/ownership types had been well designed from the get go.
> 
> Inconsistencies in syntax and special casing the typing requires the user to "be smart", because the language is "dumb". But making the compiler smarter to fix a dumb language is the wrong path. The right thing to do is to redesign what is "dumb" (the language).

i agree with you, but it's really too late to redesign. :-(
it's not about "code breaking", people just will not join D3 (or
something) developement at this stage. especially if Walter and Andrei
will not join (and i doubt they will).

On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:
> i agree with you, but it's really too late to redesign. :-(
> it's not about "code breaking", people just will not join D3 (or
> something) developement at this stage.

I don't agree. D does not have a significant set of libraries that developers depend on and also not a large installed base.

What prevents Python3 adoption is the massive amount of Python2 libraries and a perception that you loose more than you gain from switching. But people are switching to Python3... and to C++14... and to Swift... and to Go... When the installed base moves, projects move. Large installed base -> slow moving. No installed base -> free to move.

> especially if Walter and Andrei will not join (and i doubt they will).

I think you overestimate the importance of that. It does not matter who uses D today. The crux is to appeal to those who do not use it, but hacking on it does not fix it for those who have left.

Based on what people write in the forums it looks like D now appeals more to newbies coming from scripting languages and VM languages than those coming from low level C/C++. That might turn out to be a very risky market where people switch easily...

On Mon, 02 Feb 2015 09:07:37 +0000, Ola Fosheim Grøstad wrote:

> On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:
>> i agree with you, but it's really too late to redesign. :-( it's not about "code breaking", people just will not join D3 (or something) developement at this stage.
> 
> I don't agree. D does not have a significant set of libraries that developers depend on and also not a large installed base.

but to work on D3 people should be interested in D. and it seems that people who are interested in D and are ready to work on D development already have some codebases. i don't believe that they will welcome yet another codebase conversion. ;-)

>> especially if Walter and Andrei will not join (and i doubt they will).
> 
> I think you overestimate the importance of that. It does not matter who uses D today. The crux is to appeal to those who do not use it, but hacking on it does not fix it for those who have left.

but it's matter who is driving force behind the project. "yet another D fork from people you never heard about" has little chances to be successful. besides, Walter owns DMD codegen. it's not the best codegen in the world, but it's very valuable, 'cause it allows to develop D without installing llvm/gcc crap.

On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:
> but to work on D3 people should be interested in D. and it seems that people who are interested in D and are ready to
> work on D development
> already have some codebases. i don't believe that they will welcome yet
> another codebase conversion. ;-)

Mmmaybe, but I think more people would be more willing to work on the compiler if the goal is to produce a niche language of high standards. Basically, a best of breed for niche X.

When features compete in a way that makes it impossible to be the best in any niche, then that basically kills motivation (at least mine).  Complex languages that grow are usually best of breed in their niche for solving "hard problems".

D is getting complicated, but not to solve hard problems. That is not a good tradeoff.

There are plenty of simple languages for solving easy problems.

> but it's matter who is driving force behind the project. "yet another D
> fork from people you never heard about" has little chances to be
> successful.

Stability, quality and performance. Kill the less important stuff and move for performance. Performance generally trumps other parameters if you are actively getting benchmarks published IMHO.

To get performance you need to focus on one platform first.

D is expanding everywhere, even in the standard library... Not good. D cannot build "high quality anything" without staying focused. High quality means hardware optimized and best of breed.

Just take a look at the numerical library in D, basically empty... If you don't have the resources to make the numerical library look complete then leave it all to a third party.

On Mon, 02 Feb 2015 14:11:20 +0000, Ola Fosheim Grøstad wrote:

> On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:
>> but to work on D3 people should be interested in D. and it seems that people who are interested in D and are ready to work on D development already have some codebases. i don't believe that they will welcome yet another codebase conversion. ;-)
> 
> Mmmaybe, but I think more people would be more willing to work on the compiler if the goal is to produce a niche language of high standards. Basically, a best of breed for niche X.

so it should have defined niche then. sadly, D hasn't, as it tries to be "good system language", "good high-level language" and even "good scripting language" to some extent.

i, for example, see D as something intermediate between "system" and "high-level". for me it's really "better C with classes (and structs)". and lambdas, which i'm using in gcc too. and i don't really need that "@safe" and "pure" things -- hey, if compiler is able to check that, it's able to infer that, so do it and just get out of my way! ah, and "nothrow" too. let me force that if i want, but otherwise don't burden my sources.

sure, to fully exploit that (and other things) it's better to drop that oldish "object files" concept and use something like delphi's .dcu.

> When features compete in a way that makes it impossible to be the best in any niche, then that basically kills motivation (at least mine).

me too: i still can't understand what kind of language D tries to be.

> Stability, quality and performance. Kill the less important stuff and move for performance. Performance generally trumps other parameters if you are actively getting benchmarks published IMHO.

performance can be left to gcc branch: let gcc people write optimisers for us! ;-) ah, and architecture support too.

> To get performance you need to focus on one platform first.

not necessary. just stop using homegrown codegen for anything except compiler prototypes. develop new features and fixes with prototype comiler, which is able to produce working code, but doesn't even try to do "native" optimisations, and then use gcc as backend for releases.

On Monday, 2 February 2015 at 15:24:15 UTC, ketmar wrote:
> and lambdas, which i'm using in gcc too. and i don't really need that
> "@safe" and "pure" things -- hey, if compiler is able to check that, it's
> able to infer that, so do it and just get out of my way! ah, and "nothrow"
> too. let me force that if i want, but otherwise don't burden my sources.

Yeah, I'm not really into all those constraints. I want power, not limitations and tedium. ;-)

> sure, to fully exploit that (and other things) it's better to drop that
> oldish "object files" concept and use something like delphi's .dcu.

I am not familiar with that format, but using a high level intermediate representation format is the way to go for whole program optimization IMO...

> not necessary. just stop using homegrown codegen for anything except
> compiler prototypes. develop new features and fixes with prototype
> comiler, which is able to produce working code, but doesn't even try to
> do "native" optimisations, and then use gcc as backend for releases.

Well, one should look to other architectures, but getting high performance levels takes focus. I am not sure if one can get beyond C++ by spreading out on all platforms. Intel intrinsics are in the thousands, and the libraries (and high level optimizer) probably should use those where they are a good fit...

On Mon, 02 Feb 2015 19:13:13 +0000, Ola Fosheim Grøstad wrote:

>> sure, to fully exploit that (and other things) it's better to drop that oldish "object files" concept and use something like delphi's .dcu.
> 
> I am not familiar with that format, but using a high level intermediate representation format is the way to go for whole program optimization IMO...

it's practically a ".di" file, but in compact binary representation. or even a full ".d" file for that matter. it's already parsed, checked, analyzed, maybe even some code emited -- but no AST/type information is lost. well, .dcus doesn't keep AST, but D ".dcm" can. ;-)

they also can be used by tools too.

> Well, one should look to other architectures, but getting high performance levels takes focus. I am not sure if one can get beyond C++ by spreading out on all platforms. Intel intrinsics are in the thousands, and the libraries (and high level optimizer) probably should use those where they are a good fit...

i think that this is the area that can be left to "platform-specific" part of the specs. maybe even omited completely, as it's highly backend/ arch dependent. if someone want to squeeze every cycle possible, he knows that his code will be unportable mess. ;-)