www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Chapel vs D

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
The Chapel quick ref card gives a nice overview of Chapel syntax 
and features:

http://chapel.cray.com/spec/quickReference.pdf

Cray has of course geared Chapel towards non-realtime 
high-throughput computing, so it is not an alternative to 
C/C++/Rust/D for interactive applications. But the syntax is 
quite clean and the feature set makes sense.

The Chapel parameter specification has immutable value types as 
the default except for arrays, syncs, singles and atomics which 
get ref-semantics. Chapel also allows named parameters, and has 
an inout-type that copies in and out for safer multi-threading 
(avoiding spurious writes from other threads during the 
computation).

The typing/casting syntax uses postfix "expression:type" notation 
which produces clean looking casts. Mutable declarations are 
prefixed with "var". Read only references and immutable values 
are prefixed with "const".

Chapel also has yield-based iterators (generators) like Python, 
numerical-ranges (and domain maps for array indexing).

I think D needs to consider improving the syntax and the feature 
set by looking closely at competing languages. If one can improve 
D by taking on conventions from other performance oriented 
languages then D will look less weird and moving to D more 
attractive.

Chapel's syntax is cleaner looking that D, and Chapel also have 
some features that D would benefit from adopting.

I think Rust is loosing some followers on syntax alone, and D 
too. Planning for a D3 syntax upgrade with some premature 
experiments would be a good idea.
Dec 26 2014
parent reply "Israel" <tl12000 live.com> writes:
On Friday, 26 December 2014 at 11:52:27 UTC, Ola Fosheim Grøstad
wrote:

 The Chapel quick ref card gives a nice overview of Chapel 
 syntax and features:

 http://chapel.cray.com/spec/quickReference.pdf

 Cray has of course geared Chapel towards non-realtime 
 high-throughput computing, so it is not an alternative to 
 C/C++/Rust/D for interactive applications. But the syntax is 
 quite clean and the feature set makes sense.

 The Chapel parameter specification has immutable value types as 
 the default except for arrays, syncs, singles and atomics which 
 get ref-semantics. Chapel also allows named parameters, and has 
 an inout-type that copies in and out for safer multi-threading 
 (avoiding spurious writes from other threads during the 
 computation).

 The typing/casting syntax uses postfix "expression:type" 
 notation which produces clean looking casts. Mutable 
 declarations are prefixed with "var". Read only references and 
 immutable values are prefixed with "const".

 Chapel also has yield-based iterators (generators) like Python, 
 numerical-ranges (and domain maps for array indexing).

 I think D needs to consider improving the syntax and the 
 feature set by looking closely at competing languages. If one 
 can improve D by taking on conventions from other performance 
 oriented languages then D will look less weird and moving to D 
 more attractive.

 Chapel's syntax is cleaner looking that D, and Chapel also have 
 some features that D would benefit from adopting.

 I think Rust is loosing some followers on syntax alone, and D 
 too. Planning for a D3 syntax upgrade with some premature 
 experiments would be a good idea.


I think the languages out there with the cleanest looking syntax



is my Compound worded syntax with capital letters like
GetCurrentDirectory() whereas in D it looks like thisExe()

Same with how we deal with other syntax situations like input.


int ThisNumber;
ThisNumber = Console.ReadLine();

in D it looks worse with its "old" way of doing it:

int thisNumber
readf("%s", &thisNumber);


cleaner and more well structured and easier to understand.
Whenever i see this kind of syntax it hurts. Maybe its because im

The point is, I agree. Syntax like this is so terrible to look at
it hurts. I feel like i lose 10 minutes of my lifespan every time
i look at this.
Dec 26 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Israel:


 I think the languages out there with the cleanest looking syntax



Haskell and Python have a much cleaner syntax compared to 

points to quickly understand what the code means. So I think the 






 int ThisNumber;
 ThisNumber = Console.ReadLine();

 in D it looks worse with its "old" way of doing it:

 int thisNumber
 readf("%s", &thisNumber);


Do you want to use a "%d"?

A more common way to do it in D is something like:

auto inLines = readln.byLine;
immutable thisNumber = inLines.front.to!int;
inLines.popFront;



 The point is, I agree. Syntax like this is so terrible to look 
 at it hurts. I feel like i lose 10 minutes of my lifespan every 
 time i look at this.


It's also a lot a matter of getting used to it.

Bye,
bearophile
Dec 26 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 26 December 2014 at 18:38:42 UTC, bearophile wrote:

 The point is, I agree. Syntax like this is so terrible to look 
 at it hurts. I feel like i lose 10 minutes of my lifespan 
 every time i look at this.


 It's also a lot a matter of getting used to it.


I agree with this, you will get used to it.


functions, etc. After being corrected on this newsgroup for post 

http://dlang.org/dstyle.html At first it was alien but now i use 

and is IMHO a lot easier to parse when reading code. Neither is 
right or wrong but i now prefer the D style.
Dec 26 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 December 2014 at 18:38:42 UTC, bearophile wrote:

 It's also a lot a matter of getting used to it.


That is true. I got used to Motorola 68000 assembly and probably 
found it more clear than the C syntax when I used it frequently, 
but that does not mean the 68K syntax was great.

One can use "a matter of getting used to" to defend just about 
any design, but in the real world programmers often use many 
languages. Only the most hard core will spend most of their time 
with D.  "getting used to" is a bad market strategy. Familiarity 
and consistency is important.
Dec 27 2014
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 26/12/2014 18:38, bearophile wrote:



 int ThisNumber;
 ThisNumber = Console.ReadLine();

 in D it looks worse with its "old" way of doing it:

 int thisNumber
 readf("%s", &thisNumber);


 Do you want to use a "%d"?

 A more common way to do it in D is something like:

 auto inLines = readln.byLine;
 immutable thisNumber = inLines.front.to!int;
 inLines.popFront;


Or just:
int thisNumber = readln().to!int;
Dec 27 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 December 2014 at 18:16:59 UTC, Israel wrote:


 is my Compound worded syntax with capital letters like
 GetCurrentDirectory() whereas in D it looks like thisExe()

 Same with how we deal with other syntax situations like input.


 int ThisNumber;
 ThisNumber = Console.ReadLine();

 in D it looks worse with its "old" way of doing it:

 int thisNumber
 readf("%s", &thisNumber);



is geared towards autocompletion in the editor. Fortunately using 
phobos is optional, so I am more concerned about the core 
language syntax and how it expresses the desirable semantics.

E.g. Chapel has typed tuples expressed as simple parentheses. 
Tuples are convenient, but only if the syntax is the standard 
lightweight notation. A library hack is not sufficient, since 
tuples are usually used as a lightweight replacement for structs 
and lists.

The current D syntax cannot absorb more features without a 
redesign, and some features should be inverted.  It would make 
sense to look at what other languages provide in terms of 
features and how they allow programmers to express it in the 
language syntax.
Dec 27 2014