www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dart and D: features that could be used in D,

reply Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c30ce2a8976804f360a6c5
Content-Type: text/plain; charset=ISO-8859-1

A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively) but the language itself reminds
more of D to a surprising extent. Dart language has features such as:


static typing (but can also have dynamic typing, akin to std.variant, with
better support/syntax than D)
ahead of time compilation
unicode support
built in serialization/deserialization via json
annotations
mixins (used to emulate multiple inheritance)
generics
vector/AA litterals
alias (called typedef in dart), is, assert
try/catch/finally
operator overloading
properties (same parenthesis-less caller syntax as in D)
delegates (called closures)
nesting functions, 1st class functions, lambda => syntax
DDOC (called dartdoc)
D-like syntax and nesting comments,
introspection (runtime only AFAIK)

A2)
Also features that would be nice to have in D or were better designed than
in D:

* cascade operations: they perform a series of operations on the members of
a single object:
foo.bar(1)..baz(3)
equivalent to:
foo.bar(1)
foo.baz(3)

* better way to define default constructors:
class Point {
  num x;
  num y;
  num z;
  // Syntactic sugar for setting z and x before the constructor body runs.
  Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct
constructors, which can only allow to set all fields in order, without
skipping some, and doesn't allow to do anything else in the ctor.

* named constructors

* distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2

* shorthand function declaration with => (used not just for lambdas)

* for (var x in collection) //better syntax than foreach(var;collection)

* better syntax for optional positional arguments:
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in D,
that of specifying optional parameters AFTER a variadic template:
void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}

* export for libraries

* async/wait etc

* great IDE/debugger/package manager/static analyzer

also the following which I've previously proposed adding to D:

* string interpolation $variableName (or ${expression})
assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING INTERPOLATION bar');

* optional named parameters arguments (with simplest possible syntax)

* import all except specified symbols:
import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.

A3)
And then some design decisions which wouldn't work for D: everything is an
object, no struct (just class), VM, etc.

A4)
there were may previous threads regarding using D on the web via compiling
to javascript. In light of this it would seem a lot easier to compile D to
dart.

--001a11c30ce2a8976804f360a6c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>A1)</div>Google&#39;s Dart (<a href=3D"https://www.da=
rtlang.org">https://www.dartlang.org</a>) looks like a very promising repla=
cement for javascript. It can compile to javascript to ensure portability (=
but chromium runs it natively) but the language itself reminds more of D to=
 a surprising extent. Dart language has features such as:<div>
<br></div><div><br></div><div>static typing (but can also have dynamic typi=
ng, akin to std.variant, with better support/syntax than D)<br></div><div>a=
head of time compilation</div><div>unicode support</div><div>built in seria=
lization/deserialization via json=A0</div>
<div>annotations<br></div><div>mixins (used to emulate multiple inheritance=
)</div><div>generics</div><div>vector/AA litterals</div><div>alias (called =
typedef in dart), is, assert<br></div><div>try/catch/finally<br></div><div>
operator overloading</div><div>properties (same parenthesis-less caller syn=
tax as in D)</div><div>delegates (called closures)<br></div><div>nesting fu=
nctions, 1st class functions, lambda =3D&gt; syntax</div><div>DDOC (called =
dartdoc)</div>
<div>D-like syntax and nesting comments,</div><div>introspection (runtime o=
nly AFAIK)<br></div><div><br></div><div><div>A2)</div></div><div>Also featu=
res that would be nice to have in D or were better designed than in D:</div=

ions on the members of a single object:</div><div>foo.bar(1)..baz(3)</div><= div>equivalent to:</div><div>foo.bar(1)</div><div>foo.baz(3)</div><div><br> </div><div>* better way to define default constructors:<br></div><div><div>= class Point {</div><div>=A0 num x;</div><div>=A0 num y;</div><div>=A0 num z= ;</div><div>=A0 // Syntactic sugar for setting z and x before the construct= or body runs.<br> </div><div>=A0 Point(this.z, this.x){...}</div><div>}</div></div><div>This = is more explicit and flexible than D&#39;s way for default struct construct= ors, which can only allow to set all fields in order, without skipping some= , and doesn&#39;t allow to do anything else in the ctor.</div> <div><br></div><div><div>* named constructors</div><div><br></div><div>* di= stinguish integer divide (~/) vs divide (/), so that 5/2=3D2, 5~/2=3D2</div=
</div><div><br></div><div><div>* shorthand function declaration with =3D&g=

<div><br></div></div><div>* for (var x in collection) //better syntax than = foreach(var;collection)<br></div><div><br></div><div>* better syntax for op= tional positional arguments:</div><div>void fun(int x, [int y, int z=3D3]){= ...}</div> <div>Thinking of which, this would actually solve a long standing problem i= n D, that of specifying optional parameters AFTER a variadic template:</div=
<div>void fun(T...)(T args, [string file=3D__FILE__,int line=3D__LINE__]){=

<div><br></div><div>* export for libraries</div><div><br></div><div>* async= /wait etc</div><div><br></div><div>* great IDE/debugger/package manager/sta= tic analyzer</div><div><br></div><div>also the following which I&#39;ve pre= viously proposed adding to D:</div> <div><br></div><div>* string interpolation=A0$variableName (or ${expression= })</div><div><div>assert(&#39;foo. ${s.toUpperCase()} bar&#39; =3D=3D &#39;= foo. STRING INTERPOLATION bar&#39;);</div></div><div><br></div><div><div>* = optional named parameters arguments (with simplest possible syntax)</div> </div><div><div><br></div><div>* import all except specified symbols:</div>= <div>import &#39;package:lib2/lib2.dart&#39; hide foo; // Import all names = EXCEPT foo.<br></div></div><div><br></div><div><div>A3)</div></div><div> And then some design decisions which wouldn&#39;t work for D: everything is= an object, no struct (just class), VM, etc.</div><div><br></div><div>A4)= =A0</div><div>there were may previous threads regarding using D on the web = via compiling to javascript. In light of this it would seem a lot easier to= compile D to dart.</div> <div><br></div></div> --001a11c30ce2a8976804f360a6c5--
Feb 27 2014
next sibling parent "Suliman" <evermind live.ru> writes:
What needed to create language that can be run everywhere? I mean 
would it be hard to add support of running D code in web-browser?

it's better to write all logic at one language, that on 2 or 3.
Feb 27 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timothee Cour:

 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the constructor 
 body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct
 constructors, which can only allow to set all fields in order, 
 without
 skipping some, and doesn't allow to do anything else in the 
 ctor.

A variant of this idea was discussed, and I think it's a good idea.
 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 
 5~/2=2

 * shorthand function declaration with => (used not just for 
 lambdas)

Both good. But for the first you need a different syntax in D.
 * optional named parameters arguments (with simplest possible 
 syntax)

 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names 
 EXCEPT foo.

Probably both good, if well designed. Bye, bearophile
Feb 27 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
I don't like any of the syntax changes mentioned. I do like the 
suggestions for better IDEs and similar tools. We can always do 
more to improve these.
Feb 27 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour 
wrote:
 A1)
 Google's Dart (https://www.dartlang.org) looks like a very 
 promising
 replacement for javascript. It can compile to javascript to 
 ensure
 portability (but chromium runs it natively) but the language 
 itself reminds
 more of D to a surprising extent. Dart language has features 
 such as:


 static typing (but can also have dynamic typing, akin to 
 std.variant, with
 better support/syntax than D)
 ahead of time compilation
 unicode support
 built in serialization/deserialization via json
 annotations
 mixins (used to emulate multiple inheritance)
 generics
 vector/AA litterals
 alias (called typedef in dart), is, assert
 try/catch/finally
 operator overloading
 properties (same parenthesis-less caller syntax as in D)
 delegates (called closures)
 nesting functions, 1st class functions, lambda => syntax
 DDOC (called dartdoc)
 D-like syntax and nesting comments,
 introspection (runtime only AFAIK)

 A2)
 Also features that would be nice to have in D or were better 
 designed than
 in D:

 * cascade operations: they perform a series of operations on 
 the members of
 a single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)

 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the constructor 
 body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct
 constructors, which can only allow to set all fields in order, 
 without
 skipping some, and doesn't allow to do anything else in the 
 ctor.

 * named constructors

 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 
 5~/2=2

 * shorthand function declaration with => (used not just for 
 lambdas)

 * for (var x in collection) //better syntax than 
 foreach(var;collection)

 * better syntax for optional positional arguments:
 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing 
 problem in D,
 that of specifying optional parameters AFTER a variadic 
 template:
 void fun(T...)(T args, [string file=__FILE__,int 
 line=__LINE__]){...}

 * export for libraries

 * async/wait etc

 * great IDE/debugger/package manager/static analyzer

 also the following which I've previously proposed adding to D:

 * string interpolation $variableName (or ${expression})
 assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING 
 INTERPOLATION bar');

 * optional named parameters arguments (with simplest possible 
 syntax)

 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names 
 EXCEPT foo.

 A3)
 And then some design decisions which wouldn't work for D: 
 everything is an
 object, no struct (just class), VM, etc.

 A4)
 there were may previous threads regarding using D on the web 
 via compiling
 to javascript. In light of this it would seem a lot easier to 
 compile D to
 dart.

I've hear that Microsoft's equivalent so-called TypeScript was more successfully than Google's one, more people like much more TypeScript syntax and features, like I do.
Feb 27 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/27/14, 7:19 AM, Timothee Cour wrote:
 And then some design decisions which wouldn't work for D: everything is
 an object, no struct (just class), VM, etc.

In a programming language you can make everything look like an object but implement it as a primitive type. So that could work in D (but I think nobody would like it, although it can make the language much simpler).
Feb 27 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 17:48, schrieb Ary Borenszweig:
 On 2/27/14, 7:19 AM, Timothee Cour wrote:
 And then some design decisions which wouldn't work for D: everything is
 an object, no struct (just class), VM, etc.

In a programming language you can make everything look like an object but implement it as a primitive type. So that could work in D (but I think nobody would like it, although it can make the language much simpler).

Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many other languages work.
Feb 27 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 28.02.2014 13:15, schrieb Bienlein:
 On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:
 Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many
 other languages work.

An object in Smalltalk is not a primitive type. Even ints, floats, chars, etc. in Smalltalk are no primitive types but objects. Not wanting to be a rogue. Just pointing out ;-).

Yes they are, kind of, because the ones small enough to fit in registers, like SmallInteger are converted to primitive types by the JIT. The programmer cannot see it, because it is considered an implementation detail, likewise in the other environments I mentioned. -- Paulo
Feb 28 2014
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour 
wrote:
 A1)
 Google's Dart (https://www.dartlang.org) looks like a very 
 promising
 replacement for javascript. It can compile to javascript to 
 ensure
 portability (but chromium runs it natively)

No, neither Chromium nor even Chrome run it natively. Only Dartium which is a separate browser.
 * cascade operations: they perform a series of operations on 
 the members of a single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)

In D we can use with(foo) { bar(1); bar(3); } Pretty close. Dart looks like a very nice language for front-end web development indeed. If I was doing web-dev I would choose vibe.d + Dart combo. Some features like its constructors and short form of methods I would love to see in D too. As for compiling D to Dart I'm not sure that's feasible. You'll have to chop off lower half of it.
Feb 27 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 18:29, schrieb thedeemon:
 On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour wrote:
 A1)
 Google's Dart (https://www.dartlang.org) looks like a very promising
 replacement for javascript. It can compile to javascript to ensure
 portability (but chromium runs it natively)

No, neither Chromium nor even Chrome run it natively. Only Dartium which is a separate browser.

From what I understood on Dart talks last Google IO, work was planned to have V8 and Dart VM play together inside Chrome. Personally, I think unless Google pushes the language fro ChromeOS or Android, it will hardly get any real market size. Like it or not, JavaScript is good enough. On my field of work, it doesn't matter how many cool languages I know, we are usually bound by what the whole team is comfortable using, what the boss allows for and the technologies that are requested by the customers themselves. -- Paulo
Feb 27 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 27.02.2014 19:37, schrieb Craig Dillabaugh:
 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
 clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.

I didn't say I like it that much, just that it is good enough for what enterprise applications, my field of work, are about. So unless the browser vendors start supporting other languages, our customers will only ask for JavaScript, because it is easier to find guys when doing maintenance support. They don't care about Dart, TypeScript, CoffeScript, or whatever might be the flavour of the month, because it increases their problems to find people and their internal teams usually don't know those languages anyway. The same to any other language out there. Usually when I get to work on a cool language at the enterprise level, it is no longer cool, or it was brought in because some startup belonging to someone close to the CTO managed to sneak it in. The is of course my enterprise world, yours may vary. -- Paulo
Feb 27 2014
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.
Feb 27 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.

I developed 99% of the JavaScript part of an application for a year, and I have extensive JavaScript knowledge. After all that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/
Feb 27 2014
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
 wrote:
 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.

I developed 99% of the JavaScript part of an application for a year, and I have extensive JavaScript knowledge. After all that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/

Great. Now I have something to go an read for laughs whenever I feel my blood-pressure exceeding safe limits :o)
Feb 27 2014
prev sibling next sibling parent Martin Drasar <drasar ics.muni.cz> writes:
On 27.2.2014 20:54, w0rp wrote:
 I developed 99% of the JavaScript part of an application for a year, and
 I have extensive JavaScript knowledge. After all that, I wrote this.
 https://w0rp.com/blog/post/javascript-sucks/

I think it was someone on Slashdot who posted this wonderful comment: "JavaScript is a crap language that can't be fixed. If they ever add an honest garbage collector to the base language then most programs will delete themselves upon execution."
Feb 27 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:
 * optional named parameters arguments (with simplest possible syntax)

This comes up now and then. The problem with it is it makes function overloading a near impossibility to untangle.
Feb 27 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-02-27 21:43, Walter Bright wrote:

 This comes up now and then. The problem with it is it makes function
 overloading a near impossibility to untangle.

We could quite easy add support for named parameters but still require using the same position of the arguments. I don't know if those wanting named parameters would be satisfied with this though. -- /Jacob Carlborg
Mar 01 2014
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-01 15:19:29 +0000, Jacob Carlborg <doob me.com> said:

 On 2014-02-27 21:43, Walter Bright wrote:
 
 This comes up now and then. The problem with it is it makes function
 overloading a near impossibility to untangle.

We could quite easy add support for named parameters but still require using the same position of the arguments. I don't know if those wanting named parameters would be satisfied with this though.

I did implement something like that in DMD a while ago as an experiment. See the comments below that commit: https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a Walter pointed out that it should work for template arguments. I agreed, devised a plan to restructure the whole thing to be less of a hack and make it works for templates, then I had no more time to put on this. :-( This planned restructuring did lead to a transition to type-checked arrays within DMD though, so the effort wasn't completely wasted. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Mar 01 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-01 17:19, Michel Fortin wrote:

 I did implement something like that in DMD a while ago as an experiment.
 See the comments below that commit:

 https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a

I based the "quite easy" on the few changes needed in your implementation.
 Walter pointed out that it should work for template arguments. I agreed,
 devised a plan to restructure the whole thing to be less of a hack and
 make it works for templates, then I had no more time to put on this. :-(

That happens too often :(
 This planned restructuring did lead to a transition to type-checked
 arrays within DMD though, so the effort wasn't completely wasted.

Nice :) -- /Jacob Carlborg
Mar 01 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:
 * import all except specified symbols:
 import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.

As a general rule, negation features are frequently misunderstood, our brains tend to just not see the negation. One should positively import names, not negatively not import some. And there's the maintenance problem - what did the importer mean to do when the imported module adds a 'bar' name?
Feb 27 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2014 2:19 AM, Timothee Cour wrote:
 * cascade operations: they perform a series of operations on the members of a
 single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)

D has ranges and algorithms to conveniently chain operations.
 * better way to define default constructors:
 class Point {
    num x;
    num y;
    num z;
    // Syntactic sugar for setting z and x before the constructor body runs.
    Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default struct
constructors,
 which can only allow to set all fields in order, without skipping some, and
 doesn't allow to do anything else in the ctor.

D doesn't allow non-trivial default struct constructors for some good reasons, which are a long discussion we've had many times. These reasons don't apply to javascript.
 * named constructors

I don't see the point of such over using the factory method idiom.
 * distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2

Such are needed so rarely - in C they are done with the modf function, and I've never seen modf used in the wild.
 * shorthand function declaration with => (used not just for lambdas)

tomayto, tomahto :-)
 * for (var x in collection) //better syntax than foreach(var;collection)

tomayto, tomahto
 * better syntax for optional positional arguments:
 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing problem in D, that
 of specifying optional parameters AFTER a variadic template:
 void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}

Not sure what that is.
 * export for libraries

What does that mean?
 * async/wait etc

Those are a great idea, and we need to do them at some point.
Feb 27 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 * optional named parameters arguments (with simplest possible 
 syntax)

function overloading a near impossibility to untangle.

Do you have an example of the problem?
 * better way to define default constructors:
 class Point {
   num x;
   num y;
   num z;
   // Syntactic sugar for setting z and x before the 
 constructor body runs.
   Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default 
 struct constructors,
 which can only allow to set all fields in order, without 
 skipping some, and
 doesn't allow to do anything else in the ctor.

D doesn't allow non-trivial default struct constructors for some good reasons, which are a long discussion we've had many times. These reasons don't apply to javascript.

The idea of having some syntax like this is nice, it reduces the poilerplace code, making the code less noisy and reducing the probability of the currenty common bugs caused by having fields and arguments with equal or similar names: class Foo { int x; this(this.x) {} void inc(int x) { this.x += x; } }
 * shorthand function declaration with => (used not just for 
 lambdas)

tomayto, tomahto :-)

There is an enhancement request on this in Bugzilla. A shorter syntax for simple functions is handy, because one-line functions have become very common in D. Bye, bearophile
Feb 27 2014
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--047d7b33d812f0dee704f36c864f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 27, 2014 at 12:56 PM, Walter Bright
<newshound2 digitalmars.com>wrote:

 On 2/27/2014 2:19 AM, Timothee Cour wrote:

 * cascade operations: they perform a series of operations on the members
 of a
 single object:
 foo.bar(1)..baz(3)
 equivalent to:
 foo.bar(1)
 foo.baz(3)

D has ranges and algorithms to conveniently chain operations.

cascade != chaining: cascade: a.f1..f2..f3 <=> a.f1 a.f2 a.f3 chaining: a.f1.f2.f3 <=> ((a.f1).f2).f3) --047d7b33d812f0dee704f36c864f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">On Thu, Feb 27, 2014 at 12:56 PM, Walter Bright <span dir=3D"ltr">&= lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newshoun= d2 digitalmars.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"">On 2/27/2014 2:19 AM, Timothee Cour wrote:= <br> </div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor= der-left-style:solid;padding-left:1ex"> * cascade operations: they perform a series of operations on the members of= a<br> single object:<br> foo.bar(1)..baz(3)<br> equivalent to:<br> foo.bar(1)<br> foo.baz(3)<br> </blockquote> <br></div> D has ranges and algorithms to conveniently chain operations.</blockquote><= div><br></div><div>cascade !=3D chaining:</div><div><br></div><div>cascade:= </div><div>a.f1..f2..f3</div><div>&lt;=3D&gt;</div><div><div>a.f1</div></di= v> <div><div>a.f2</div></div><div><div>a.f3</div></div><div><br></div><div><di= v>chaining:</div><div>a.f1.f2.f3</div><div>&lt;=3D&gt;</div><div>((a.f1).f2= ).f3)</div><div><br></div></div></div></div></div> --047d7b33d812f0dee704f36c864f--
Feb 27 2014
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--bcaec5523dcce11faa04f36cb404
Content-Type: text/plain; charset=ISO-8859-1

  * better syntax for optional positional arguments:
 void fun(int x, [int y, int z=3]){...}
 Thinking of which, this would actually solve a long standing problem in
 D, that
 of specifying optional parameters AFTER a variadic template:
 void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}

Not sure what that is.

http://d.puremagic.com/issues/show_bug.cgi?id=8687 : Variadic templates do not work properly with default arguments
  * export for libraries

What does that mean?

http://wiki.dlang.org/DIP45 --bcaec5523dcce11faa04f36cb404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= -width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi= ng-left:1ex"> <div class=3D""><br></div><div class=3D""> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> * better syntax for optional positional arguments:<br> void fun(int x, [int y, int z=3D3]){...}<br> Thinking of which, this would actually solve a long standing problem in D, = that<br> of specifying optional parameters AFTER a variadic template:<br> void fun(T...)(T args, [string file=3D__FILE__,int line=3D__LINE__]){...}<b= r> </blockquote> <br></div> Not sure what that is.<br></blockquote><div>=A0</div><div><a href=3D"http:/= /d.puremagic.com/issues/show_bug.cgi?id=3D8687">http://d.puremagic.com/issu= es/show_bug.cgi?id=3D8687</a> : Variadic templates do not work properly wit= h default arguments<br> </div><div><br></div><div><br></div><div><br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le= ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> * export for libraries<br> </blockquote> <br> What does that mean?<br></blockquote><div>=A0</div><div><a href=3D"http://w= iki.dlang.org/DIP45">http://wiki.dlang.org/DIP45</a></div><div><br></div></= div></div></div> --bcaec5523dcce11faa04f36cb404--
Feb 27 2014
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c2cba4ebf74304f36ccf9d
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 27, 2014 at 2:40 PM, bearophile <bearophileHUGS lycos.com>wrote:

 Walter Bright:


  * optional named parameters arguments (with simplest possible syntax)

overloading a near impossibility to untangle.

Do you have an example of the problem?

Not sure what the problem would be. We could apply the same rules as for template overloading, ie error when there's a potential ambiguity (or even disable overloading for functions with named parameter until details are ironed out). Many languages have this, for good reason (discussed, again, many times). --001a11c2cba4ebf74304f36ccf9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= hu, Feb 27, 2014 at 2:40 PM, bearophile <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:bearophileHUGS lycos.com" target=3D"_blank">bearophileHUGS lycos.com</= a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Walter Bright:<div class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * optional named parameters arguments (with simplest possible syntax)<br> </blockquote> This comes up now and then. The problem with it is it makes function overlo= ading a near impossibility to untangle.<br> </blockquote> <br></div> Do you have an example of the problem?</blockquote><div><br></div><div>Not = sure what the problem would be. We could apply the same rules as for templa= te overloading, ie error when there&#39;s a potential ambiguity (or even di= sable overloading for functions with named parameter until details are iron= ed out). Many languages have this, for good reason (discussed, again, many = times).</div> <div><br></div><div>=A0</div></div></div></div> --001a11c2cba4ebf74304f36ccf9d--
Feb 27 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
We could kinda do named parameters today like this:

ParameterTypeTuple!foo args;
args.named_param = 3;
foo(args);

It would be nice if we could declare a variable inside a 
with(auto x = foo) like we can in if() too.
Feb 27 2014
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--047d7b33d4fe31867f04f36d0875
Content-Type: text/plain; charset=ISO-8859-1

  * better way to define default constructors:
 class Point {
    num x;
    num y;
    num z;
    // Syntactic sugar for setting z and x before the constructor body
 runs.
    Point(this.z, this.x){...}
 }
 This is more explicit and flexible than D's way for default struct
 constructors,
 which can only allow to set all fields in order, without skipping some,
 and
 doesn't allow to do anything else in the ctor.

D doesn't allow non-trivial default struct constructors for some good reasons, which are a long discussion we've had many times. These reasons don't apply to javascript.

I don't recall this syntax 'Point(this.z, this.x){...}' ever being discussed; can you please provide a link? * it avoids the following common bug: struct Point{int x;int y;} auto a=Point(1,2,3); //later on we add a field: struct Point{int x; int a; int y; } //woops! * less boilerplate / more DRY / more explicit: struct Point{ Foo x=32; Bar y; Baz z; this(this.y, this.z){} //instead of this(Bar y, Baz z){this.y=y;this.z=z;} } This is arguably a preferable syntax. --047d7b33d4fe31867f04f36d0875 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= -width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi= ng-left:1ex"> <div class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> * better way to define default constructors:<br> class Point {<br> =A0 =A0num x;<br> =A0 =A0num y;<br> =A0 =A0num z;<br> =A0 =A0// Syntactic sugar for setting z and x before the constructor body r= uns.<br> =A0 =A0Point(this.z, this.x){...}<br> }<br> This is more explicit and flexible than D&#39;s way for default struct cons= tructors,<br> which can only allow to set all fields in order, without skipping some, and= <br> doesn&#39;t allow to do anything else in the ctor.<br> </blockquote> <br></div> D doesn&#39;t allow non-trivial default struct constructors for some good r= easons, which are a long discussion we&#39;ve had many times. These reasons= don&#39;t apply to javascript.<br></blockquote><div><br></div><div>I don&#= 39;t recall this syntax &#39;Point(this.z, this.x){...}&#39; ever being dis= cussed; can you please provide a link?</div> <div><br></div><div>* it avoids the following common bug:</div><div><br></d= iv><div>struct Point{int x;int y;}</div><div>auto a=3DPoint(1,2,3);=A0</div=
<div>//later on we add a field: struct Point{int x;=A0int a;=A0int y; }=A0=

<div>//woops!</div><div><br></div><div><div>* less boilerplate / more DRY /= more explicit:</div></div><div><br></div><div><div>struct Point{</div><div=
Foo x=3D32;</div><div>Bar y;</div><div>Baz z;</div><div>this(this.y, this.=

</div><div>}</div></div><div><br></div><div><br></div><div>This is arguably= a preferable syntax.</div><div><br></div><div><br></div><div><br></div><di= v><br></div><div><br></div><div>=A0</div></div></div></div> --047d7b33d4fe31867f04f36d0875--
Feb 27 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-27 at 19:20 +0100, Paulo Pinto wrote:
[…]
  From what I understood on Dart talks last Google IO, work was planned 
 to have V8 and Dart VM play together inside Chrome.

Dartium is a build of Chromium with both, so this is very much the direction that is possible.
 Personally, I think unless Google pushes the language fro ChromeOS or 
 Android, it will hardly get any real market size.
 
 Like it or not, JavaScript is good enough.
 
 On my field of work, it doesn't matter how many cool languages I know,
 we are usually bound by what the whole team is comfortable using, what 
 the boss allows for and the technologies that are requested by the 
 customers themselves.

Dart has a JavaScript translation back end, so could have a role very much like CoffeeScript – which arguably hasn't been that successful given jQuery, Backbone, Ember, Angular, etc. Ceylon has both JVM and JavaScript back ends and is targetted at end-to-end single language working: Ceylon in the browser, Ceylon on the server. If some of the FUD and prejudice that is being put about by innovation haters in the Javaverse can be overcome, I think Ceylon could be a big player in the game of Web applications and services. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 27 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh 
 wrote:
 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.

I developed 99% of the JavaScript part of an application for a year, and I have extensive JavaScript knowledge. After all that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/

Craig&w0rp I really do understand yeez. Really. At the moment I'm working with JS (again). Nightmare. Disaster. The server side is programmed in D, the user (client) side needs JS, ain't no other way. I have made a real, real, real, reeeeel effort, I've tried to replicate, mimic, emulate, imitate ... (running out of words here) every good programming pattern ever invented. But to no avail. JS is madness and I seriously don't understand why it has survived the way it is, why people just didn't abandon it years ago. It is madness. Frustration. Alienation. Every time I write something in JS, I feel like a complete programming novice, with the only difference that I know exactly what I want and how I would do it in any other programming language. But not so in JS. It defies reason and common human logic. JS degrades programmers. Years of experience are naught, you have to beg and cajole, you're at the mercy of a psychopathic tyrant. Whenever I program in JS I become highly irritable. When I program in D, I'm calm, I know what I want, and I know I will get it. I don't understand why we haven't got over JS yet. The Internet is so important and we still have to program things in JS. I don't get it. Now don't mention PHP with me ...
Feb 28 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 11:21:51 UTC, Chris wrote:
 On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
 On Thursday, 27 February 2014 at 18:37:51 UTC, Craig 
 Dillabaugh wrote:
 On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto 
 wrote:
 clip
 Like it or not, JavaScript is good enough.

Really? I've been stuck for the past week or so trying to put together a browser based UI using JavaScript + HTML for a work related project. It has been a painful experience. In fairness to JavaScript, I didn't know the language very well coming in, but still I've found working in this setting rather frustrating. If the future of applications is really client-server based applications, where the client is basically a VM (if we consider the browser a VM of sorts) surely there is room for a better development model than this HTML + Javascript mongrel.

I developed 99% of the JavaScript part of an application for a year, and I have extensive JavaScript knowledge. After all that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/

Craig&w0rp I really do understand yeez. Really. At the moment I'm working with JS (again). Nightmare. Disaster. The server side is programmed in D, the user (client) side needs JS, ain't no other way. I have made a real, real, real, reeeeel effort, I've tried to replicate, mimic, emulate, imitate ... (running out of words here) every good programming pattern ever invented. But to no avail. JS is madness and I seriously don't understand why it has survived the way it is, why people just didn't abandon it years ago. It is madness. Frustration. Alienation. Every time I write something in JS, I feel like a complete programming novice, with the only difference that I know exactly what I want and how I would do it in any other programming language. But not so in JS. It defies reason and common human logic. JS degrades programmers. Years of experience are naught, you have to beg and cajole, you're at the mercy of a psychopathic tyrant. Whenever I program in JS I become highly irritable. When I program in D, I'm calm, I know what I want, and I know I will get it. I don't understand why we haven't got over JS yet. The Internet is so important and we still have to program things in JS. I don't get it. Now don't mention PHP with me ...

"There is another option here. Use another programming language." Thanks for this blog. Whenever I program in JS everything feels rather 'undefined'. I would love to see the day when JS becomes obsolete.
Feb 28 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Chris:

    Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps. I suggest to use TypeScript (http://www.typescriptlang.org/ ), it has static types, more Java-style classes, better modules, and more; that give a more tidy and ordered kind of coding. If JavaScript gains integers too, programming in TypeScript probably becomes bearable even for die hard D programmers :-) Bye, bearophile
Feb 28 2014
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:
 Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and 
 many other languages work.

An object in Smalltalk is not a primitive type. Even ints, floats, chars, etc. in Smalltalk are no primitive types but objects. Not wanting to be a rogue. Just pointing out ;-).
Feb 28 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
 Chris:

   Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps.

Unfortunately, you cannot get experienced in JS, there's always a new pitfall and the more you know it the more you hate it. If you don't hate it, you don't know it. On the bright side of things, JS teaches you how _not_ to do things and it makes you appreciate other languages, real programming languages. Programming is like this: Abstract concept of what you wanna do > find out how to do it in C/Java/D/C#/Python ... JS Programming is like this: Abstract concept of what you wanna do > find out how ... > wait, why the f***k is it not > stackoverflow > ah, you cannot do this in JS > ah, you can, but you have to reinvent the wheel > now! > wait, now, why the f***k > loop through the above ...
 I suggest to use TypeScript (http://www.typescriptlang.org/ ), 
 it has static types, more Java-style classes, better modules, 
 and more; that give a more tidy and ordered kind of coding. If 
 JavaScript gains integers too, programming in TypeScript 
 probably becomes bearable even for die hard D programmers :-)

Thanks a million, I'll check it out.
 Bye,
 bearophile

Feb 28 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
 Chris:

   Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps. I suggest to use TypeScript (http://www.typescriptlang.org/ ),

Ah, no, it's MS. So is Silverlight. Don't like proprietary stuff. If Ceylon is real open source, great. I'm still dreaming of a language that will replace JS, not just compile to JS.
Feb 28 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 We could quite easy add support for named parameters but still 
 require using the same position of the arguments. I don't know 
 if those wanting named parameters would be satisfied with this 
 though.

I think requiring the same position of the arguments goes against one of the main points of having named arguments. A (temporarily?) solution to Walter's problem (has someone shown examples of the problem?) is to just not allow the use of named arguments for overloaded functions. This is not a large problem because when you have named arguments, you have less need for function overloading. Bye, bearophile
Mar 01 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
 Chris:

   Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps. I suggest to use TypeScript (http://www.typescriptlang.org/ ), it has static types, more Java-style classes, better modules, and more; that give a more tidy and ordered kind of coding. If JavaScript gains integers too, programming in TypeScript probably becomes bearable even for die hard D programmers :-) Bye, bearophile

And now with full(native, i.e., not using a plug-in) support in Visual Studio 2013 check out http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis al-studio-2013.aspx ;)
Mar 01 2014
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:
 On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
 Chris:

  Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps. I suggest to use TypeScript (http://www.typescriptlang.org/ ), it has static types, more Java-style classes, better modules, and more; that give a more tidy and ordered kind of coding. If JavaScript gains integers too, programming in TypeScript probably becomes bearable even for die hard D programmers :-) Bye, bearophile

And now with full(native, i.e., not using a plug-in) support in Visual Studio 2013 check out http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis al-studio-2013.aspx ;)

As soon as Microsoft releases a Linux version I will be sure to try it out :o)
Mar 01 2014
prev sibling parent "Asman01" <jckj33 gmail.com> writes:
On Saturday, 1 March 2014 at 18:57:03 UTC, Craig Dillabaugh wrote:
 On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:
 On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
 Chris:

 Every time I write something in JS, I feel like a complete 
 programming novice,

Probably that's part of the problem. More experience in a language helps. I suggest to use TypeScript (http://www.typescriptlang.org/ ), it has static types, more Java-style classes, better modules, and more; that give a more tidy and ordered kind of coding. If JavaScript gains integers too, programming in TypeScript probably becomes bearable even for die hard D programmers :-) Bye, bearophile

And now with full(native, i.e., not using a plug-in) support in Visual Studio 2013 check out http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-vis al-studio-2013.aspx ;)

As soon as Microsoft releases a Linux version I will be sure to try it out :o)

Well, you will need to wait a while. :P
Mar 01 2014