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.

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.

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

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.

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.

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).

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.

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.

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

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.