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/

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)

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

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

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.

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?

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.

Walter Bright:

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

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

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)

>
>
>
>  * 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