Why bother?

[Jack Bond]

If you're going to handcuff yourselves with backwards compatibility
with JavaScript, why bother with this language? Please google, make
this a real language, which means, "borrow" lots of stuff from C#. For
example.

You need (in no particular order)
A GUID / UUID type.
Reserve keywords such as 'from, "where', 'select' -> LINQ is awesome,
if you're not going to even plan for it, don't waste everyone's time.
delegates -> One of the reasons Java sucks is it doesn't have these.
task/async/wait support

"Dart code is always single threaded. There is no shared-state
concurrency in Dart"

What genius thought that up? Seriously? The whole point of a
JavaScript replacement would be to have a language that doesn't suck
running in the browser. So far, Dart appears to be nothing more than
another POS language. You've completely embarrassed yourselves by
putting out this .03 "draft."

[Ladislav Thon]

My personal opinions:

A GUID / UUID type.

Not necessary.

 

Reserve keywords such as 'from, "where', 'select' -> LINQ is awesome,
if you're not going to even plan for it, don't waste everyone's time.

Not necessary.

Some provisions for extensibility (internal DSLs) very much needed, though.

 

delegates -> One of the reasons Java sucks is it doesn't have these.

Closures. It's there.

 

task/async/wait support

"Dart code is always single threaded. There is no shared-state
concurrency in Dart"

Threading is known to be the worst way of concurrency ever. Actors and message passing -- it's there.

LT

[Michael Hendricks]

Many of your questions have come up before on the mailing list.  You might find some valuable answers by searching the archives available at https://groups.google.com/a/dartlang.org/group/misc/topics  Since Dart is still very young, it doesn't have a proper FAQ (that I'm aware of).  Google employees have said that improved documentation and design explanations are on their list of things to do.

Having said that, the language is intentionally in early draft stage.  Google didn't bring Dart down off the mountain.  They want to shape it based on feedback such as yours.

As for your specific questions: a UUID type should be easy enough to implement as a library, LINQ has been discussed in the forum and issue tracker, Dart concurrency is handled with isolates (like Erlang processes), you might offer a suggestion for you want delegation to work in Dart.

Welcome to the community!

-- 

Michael

[Bob Nystrom]

Everything Michael said is spot-on. In addition:

On Wed, Oct 19, 2011 at 11:29 AM, Jack Bond <jackh...@gmail.com> wrote:

delegates -> One of the reasons Java sucks is it doesn't have these.

Like this?

() => "I'm a function!";

task/async/wait support

Async is something lots of people on the team care deeply about. There are a bunch of approaches we want to investigate (none of which are shared mutable state + locks and... ugh). Everything from futures/promises, C#-style async/await, node-style callbacks, etc. Dart is pretty conservative about most of its features and concurrency is an area where consensus hasn't emerged yet about the best way to do it, so we want to try a few.

In particular, we have someone on the team who's put a lot of thought into C#-style async/await. With luck, we'll get a chance to try it out, but I have no idea when or if that will happen.

"Dart code is always single threaded. There is no shared-state
concurrency in Dart"

What genius thought that up? Seriously?

Probably Lars or Kasper. We have a few geniuses on the team, so I'd have to track down which particular one made this decision.

- bob

[Jack Bond]

On Oct 19, 11:40 am, Ladislav Thon <ladi...@gmail.com> wrote:
> My personal opinions:
>
> A GUID / UUID type.
>
>
>
> Not necessary.

Well NOTHING is necessary, but if that's you're criteria when
designing a language, don't bother designing a new language.

which is better...

(from p in CollectionOne
join q in CollectionTwo on p.ID equals q.ID
where p.Price > q.Price
select p).Skip(5).Take(10)

or some horrific impossible to read nested for loops? If a new general
purpose language doesn't have LINQ like functionality, it's a complete
JOKE.

[arul]

Most of the discussion around LINQ support happened in this issue: http://code.google.com/p/dart/issues/detail?id=13
It is likely someday you'll find LINQ support, Dart is not there yet.

--

Arul

http://expertstalk.org

@dartdeveloper

[Ladislav Thon]

which is better...

(from p in CollectionOne
join q in CollectionTwo on p.ID equals q.ID
where p.Price > q.Price
select p).Skip(5).Take(10)

or some horrific impossible to read nested for loops?

QBE, much like in MongoDB for example. I hate SQL. Working with data is important, but these SQL-like constructs? Seriously?

Well, this gets pretty heated and unconstructive. Let's calm things down.

LT

[Jack Bond]

On Oct 19, 1:46 pm, Ladislav Thon <ladi...@gmail.com> wrote:

> QBE, much like in MongoDB for example. I hate SQL. Working with data is
> important, but these SQL-like constructs? Seriously?
>
> Well, this gets pretty heated and unconstructive. Let's calm things down.
>
> LT

MongoDB? Do you even know what LINQ is? And I'm not talking LINQ to
SQL. I'm talking querying, joining, selecting, etc, etc in memory
collections. The resulting code is 1000x times more concise, self-
documenting, and maintainable. Designing a new general purpose
language without it being a top rated priority is absurd. Go ahead and
write a nested for loop that performs the operation I described. The
code will look ridiculous compared to the LINQ equivalent.

[Bob Nystrom]

On Wed, Oct 19, 2011 at 1:59 PM, Jack Bond <jackh...@gmail.com> wrote:

Go ahead and
write a nested for loop that performs the operation I described. The
code will look ridiculous compared to the LINQ equivalent.

As LINQ itself shows, it isn't necessary to have declarative syntax in order to have a declarative API. LINQ itself can fully be used without using the SQL keyword syntax they added to C#:

collection.Where((i) => i < 100).Skip(5).Take(10);

The advantage of doing this at the library level is:

1. Different users can use different libraries that fit their uses. Everyone isn't using SQL, so "join" "select", et. al. aren't the right vocabulary for all users.

2. Libraries evolve faster than languages. When you're talking client-side web languages, they evolve much faster.

3. You can deprecate a library. It's very hard, if not impossible, to remove a language feature.

Instead of screaming that we need to add SQL syntax to Dart's grammar, I think we should be figuring out how to make Dart flexible enough that you don't need to change the grammar in order to define a beautiful API for doing SQL queries.

- bob

[Pimm Hogeling]

Hey Jack,

Thanks for contributing!

I think it might be wise to describe a concrete proposal, and send them in. It is easier to discuss "we could change feature X so it …" than "Dart should be more like Y". I find this a very decent and constructive proposal: https://code.google.com/p/dart/issues/detail?id=44

Hope to see your ideas soon.

2011/10/19 Jack Bond <jackh...@gmail.com>

[Jack Bond]

On Oct 19, 2:14 pm, Bob Nystrom <rnyst...@google.com> wrote:

> As LINQ itself shows, it isn't necessary to have declarative *syntax* in
> order to have a declarative *API*. LINQ itself can fully be used without

> using the SQL keyword syntax they added to C#:

Your example conveniently didn't do a join or select a new anonymous
type.

> 1. Different users can use different libraries that fit their uses. Everyone
> isn't using SQL, so "join" "select", et. al. aren't the right vocabulary for
> all users.

SQL is universal and this isn't even about SQL. It's about a general
purpose querying syntax.

> 2. Libraries evolve faster than languages. When you're talking client-side

> web languages, they evolve *much* faster.

Much better at the language level. Client-side web languages evolve
much faster??? Now you're just making stuff up. There is ONE AND ONLY
one client-side web language, and it has hardly evolved at all. That's
the problem.

> 3. You can deprecate a library. It's very hard, if not impossible, to remove
> a language feature.

Strawman argument.

“Its syntax, while uninspiring, is familiar and easy to pick up for
millions of programmers,” Nystrom wrote.

Yup. Currently, not is it only uninspiring, it's downright offensive
how little it aspires to. You guys are getting your asses handed to
you by Oracle because of Java, and you're fiddling around trying to
appease a bunch of JavaScript "programmers" who don't even know their
language sucks. Who exactly is this latest google "throw some shit up
and see if it sticks" project/language supposed to appeal to? I can
tell you right now, there are a lot of Microsoft programmers out there
looking for an alternative, but they'll see this and simply say, yep,
those clowns just don't get it. (Especially if they've already seen
the Android SDK.)

[Pimm Hogeling]

2011/10/19 Jack Bond <jackh...@gmail.com>

Much better at the language level. Client-side web languages evolve
much faster??? Now you're just making stuff up. There is ONE AND ONLY
one client-side web language, and it has hardly evolved at all. That's
the problem.

If I understood Bob's reply correctly, he said that libraries evolve faster than languages, and that this is particularly true for client-side web language ecosystems. So basically: libraries written for a client-side web languages evolve much faster than that client-side web languages itself. To give an example: jQuery evolves faster than JavaScript.

[John Wells]

On Wed, Oct 19, 2011 at 5:43 PM, Jack Bond <jackh...@gmail.com> wrote:

Yup. Currently, not is it only uninspiring, it's downright offensive
how little it aspires to. You guys are getting your asses handed to
you by Oracle because of Java, and you're fiddling around trying to
appease a bunch of JavaScript "programmers" who don't even know their
language sucks. Who exactly is this latest google "throw some shit up
and see if it sticks" project/language supposed to appeal to? I can
tell you right now, there are a lot of Microsoft programmers out there
looking for an alternative, but they'll see this and simply say, yep,
those clowns just don't get it. (Especially if they've already seen
the Android SDK.)

So much hate, so little time...if you don't like/want/need Dart, then move along. If, on the other hand, you can positively contribute, then by all means do so.

I'm really surprised at how up-in-arms some folks are about Dart. It's like someone offered to build them a car and hand it over for free, and instead of being grateful, they throw up their hands in anger because it's not a four-wheel drive or because it doesn't include navigation. I mean come on people...Google is providing this for free...but they're not forcing anyone to use it. Troll some other language list please.

[Brook Monroe]

* Are you deliberately trying to be offensive? I have no clue why you
think the angry tone is getting you anywhere. That "smartest guy in
the room" attitude is off-putting--and incorrect. (I don't work for
Google. I don't have to be diplomatic about this.)

* If you think full thread-based concurrency in a browser environment
is a good idea (consider the current HTML5 "web workers" idea, which
is the merry road to Hell, both IMHO and based on experience), then
one has to ask what you're trying to write. It seems to me that a lot
of what you're aiming for should be handled by back end processes
running in languages more native to the server side, with a nice Dart
front end managing all the wobblies and wombles facing the end-user
and smoothing over the platform differences. While JS or Dart could
be used to write thick clients, after 15 years in this particular end
of the business (and 35 years total), I'm of the mind that it's a bad
idea to plant a lot of business logic on the front end.

* If you have a better idea, why not write that spec out and post it
for review? Please give us the opportunity to savor the vision you
have for the future of web-based development.

[Matt Shulman]

On Thu, Oct 20, 2011 at 7:59 PM, Brook Monroe <brook....@gmail.com> wrote:
> * Are you deliberately trying to be offensive?  I have no clue why you
> think the angry tone is getting you anywhere.  That "smartest guy in
> the room" attitude is off-putting--and incorrect.  (I don't work for
> Google. I don't have to be diplomatic about this.)
>
> * If you think full thread-based concurrency in a browser environment
> is a good idea (consider the current HTML5 "web workers" idea, which
> is the merry road to Hell, both IMHO and based on experience),

I would be interested in more detail about what problems you
encountered using web workers.

[Brook Monroe]

I have a problem with the idea of running so-called "heavyweight"
processes (as they're described) in the browser. In my experience
that sort of thing should be running on the metal somewhere else, with
only the results coming back to the display layer. So, my complaint
begins with the entire concept, and not so much with the execution.
It just seems like borrowing trouble.

On Oct 20, 11:02 am, Matt Shulman <mat...@google.com> wrote:

[Matt Shulman]

On Thu, Oct 20, 2011 at 8:08 AM, Brook Monroe <brook....@gmail.com> wrote:
> I have a problem with the idea of running so-called "heavyweight"
> processes (as they're described) in the browser.  In my experience
> that sort of thing should be running on the metal somewhere else, with
> only the results coming back to the display layer.  So, my complaint
> begins with the entire concept, and not so much with the execution.
> It just seems like borrowing trouble.

OK, thanks. One of the goals with dart isolates is that the code can
be (more or less) portable between a background isolate running in the
browser, and an isolate running on a server. But, if you're doing
something like image processing of a video stream sourced from a
camera feeding into the browser, you'll probably want your isolates
running in the browser (each processing parts of the video stream in
parallel) so they can be co-located with the data.

[Brook Monroe]

Definitely in favor of isolates as a way of handling these tasks as
opposed to web workers or concurrency via local multi-threading. My
complaint with Isolates revolves only around some issues of syntax
which I find too opaque for prime-time; I understand from another
thread that the team is still looking at this. On the whole I like
Dart as a potential way forward to more well-designed web apps.

On Oct 20, 11:24 am, Matt Shulman <mat...@google.com> wrote:

[Benjamin Gudehus]

You guys are getting your asses handed to
you by Oracle because of Java, and you're fiddling around trying to
appease a bunch of JavaScript "programmers" who don't even know their
language sucks.

JavaScript is beautiful. There are several astounding concepts I stumbled upon 

around this language and frameworks based on it.

Go ahead and
write a nested for loop that performs the operation I described. The
code will look ridiculous compared to the LINQ equivalent.

LINQ (without keyword syntax) is basically a fluent interface with some higher functions and

somethink like object notation (anonymous objects called in c#).

I regulary use something similar to LINQ in languages like Ruby, Groovy and Javascript 

instead of for-loops.

Ruby -- for instance -- has an Enumerable type with methods like any?(), all?(), 

select(), each(). Underscore for Javascript is inspired by the Ruby Enumerabled.

In JQuery one uses $.each(function()) or $.filter(function()). There is even an LINQ-like 

library for Javascript (jslinq).

I think there would be no big deal to build an LINQ library for Dart. Maybe Dart

could support somethink like AST-transformation for an implementation of the LINQ

keyword syntax.

[Quildreen Motta]

2011/10/19 Jack Bond <jackh...@gmail.com>

If you're going to handcuff yourselves with backwards compatibility
with JavaScript, why bother with this language? Please google, make
this a real language, which means, "borrow" lots of stuff from C#. For
example.

The lack of "revolutional" features at a first glance threw me off a little too, but the language is okay. I don't see how "borrow lots of stuff from C#" would be a good thing. Borrowing lots of stuff from Racket, Haskell, Clojure, Go and other interesting (in a sort-of novelty way, oftentimes) would be better.

You need (in no particular order)
A GUID / UUID type.

I don't see why that should be built-in.
 

Reserve keywords such as 'from, "where', 'select' -> LINQ is awesome,
if you're not going to even plan for it, don't waste everyone's time.

I don't see how an internal, fixed DSL for working with data is better than a language that allows you to create DSLs such that libraries can build on that and create specific solutions for specific problems. Yes, working with data is an specific problem, which a SQL-like syntax might just not cut it, unless you're working with relational databases.

As Bob pointed out, libraries evolve in a much faster pace than languages do. This is even more true for the web because you have several heterogeneous platforms that you just can't deprecate -- thus, a language can only grow through evolution, which is never a good thing (see ES4 and ES.next), a minor mistake in the process and you're burdened with it forever, basically.

On the other hand, APIs can change, they are generic and will run equal no matter the platform. So, if we were given a way of working nicely with DSLs in Dart, you could have all the goods, none of the bads.

 

delegates -> One of the reasons Java sucks is it doesn't have these.

Sorry? I think you're missing the part where Dart is a dynamically typed language with first-class functions and elegant/expressive function signatures.
 

task/async/wait support

I think there's some discussion on co-routines or some such going on.

"Dart code is always single threaded. There is no shared-state
concurrency in Dart"

As pointed out, you most likely don't want threads with shared-state. No, seriously.

As far as I can see, your whole post seems to read as "Dart is not C#, it sucks."

1.) Well, Haskell and Clojure are not C# either, they are rather awesome languages none-the-less.

2.) Dart is still in early stages of development, it's design is not locked-down. There's room for change, but please, unreasonable, unfounded and terribly written critics are not going to help. If you think Dart lacks a feature X, that happens to match the design goal of the language or a specific use-case that should be treated at the language-level, by any means, write a proposal for it, and describe why the language should have it, what are the use cases that the particular feature cover and such important stuff. Otherwise we're just going to run over and over again about pointless stuff, which doesn't really help much.

[Fabio Kaminski]

the title to this email should be corrected to: "Why bother.. to
answer this email" :)