Why did Google make a new, old-ish language? Why not innovate?

[Daniel]

How about:

1. pattern matching
2. immutable types
3. type inference
4. significant indentation (vs. a slurry of curly braces)
5. "real" static typing

There's nothing here to make a programmer's job easier.

[Quildreen Motta]

Well, "real" static typing doesn't necessarily makes the programmer's job easier. It makes the *compiler/JIT*'s job easier. But I do agree with the point, I was expecting something more innovative, as ECMAScript is already going through the path of evolution, we need more languages that present revolutionary solutions for the problems in webdev.

2011/10/13 Daniel <daniel...@gmail.com>

[John Tamplin]

On Thu, Oct 13, 2011 at 12:09 PM, Quildreen Motta <quil...@gmail.com> wrote:

Well, "real" static typing doesn't necessarily makes the programmer's job easier. It makes the *compiler/JIT*'s job easier. But I do agree with the point, I was expecting something more innovative, as ECMAScript is already going through the path of evolution, we need more languages that present revolutionary solutions for the problems in webdev.

Are we really saying things like the original poster's "things I like that aren't in Dart" list are really "revolutionary solutions for the problems in webdev"?

Dart isn't intended to be an experimental academic language.

--
John A. Tamplin
Software Engineer (GWT), Google

[Daniel]

I should have said: those are examples of innovations that have
recently entered the mainstream. I don't necessarily expect Dart to
incorporate those features. But I was hoping for *some* productivity
boosts.

On the other hand, there are features that have been discredited, or
drastically improved upon, and I wonder why include them? Why not
offer alternatives?

On Oct 13, 11:15 am, John Tamplin <j...@google.com> wrote:

[Quildreen Motta]

2011/10/13 John Tamplin <j...@google.com>

On Thu, Oct 13, 2011 at 12:09 PM, Quildreen Motta <quil...@gmail.com> wrote:

Well, "real" static typing doesn't necessarily makes the programmer's job easier. It makes the *compiler/JIT*'s job easier. But I do agree with the point, I was expecting something more innovative, as ECMAScript is already going through the path of evolution, we need more languages that present revolutionary solutions for the problems in webdev.

Are we really saying things like the original poster's "things I like that aren't in Dart" list are really "revolutionary solutions for the problems in webdev"?

Not necessarily, but I was expecting at least a good way of writing DSLs. The web is way to heterogeneous for a fixed-syntax language -- though that's the opinion of a Lisper. Also some syntax for concurrency (à lá Go channels).
 

Dart isn't intended to be an experimental academic language.

True. I guess that by "revolutionary" I meant one language that didn't just include the same old semantics and limitations that most current solutions -- for the web -- have. Though I do think Dart is less expressive than JS, mainly by the lack of [trait] composition, perhaps.

On the other hand, Dart is still a work in progress and from what I gather from this list, not locked down yet, so there's plenty of room to include some tools for productivity on top of the core. I do think most of the core is pretty solid, however. So that's already a good point in favour of Dart.

[Bob Nystrom]

On Thu, Oct 13, 2011 at 8:58 AM, Daniel <daniel...@gmail.com> wrote:

How about:

1. pattern matching

There's a proposal floating around for that, and it may happen at some point (or it may not). I like pattern matching, but I find it less critical in OOP languages than I do in functional ones.

 

2. immutable types

Const constructors give you complete deep immutability with some limitations. If you need a little more flexibility, final fields let you express as much immutability as most other languages. Dart lacks shared-state concurrency, so immutability is less important here.

 

3. type inference

Dynamic languages don't need type inference. :) Dart does have an optional type system but it's mostly a dynamic language.

 

4. significant indentation (vs. a slurry of curly braces)

That's not really an innovation: there's nothing rocket science about it. Some people like it, some people don't. Dart is aiming to be easy for existing programmers to learn and, for better or worse, the majority of the world's coders are not currently using a significant indentation language.

5. "real" static typing

Static typing isn't an innovation, it's been around forever. Your question here isn't that Dart isn't "innovative" enough, it's that Dart doesn't have a feature you like (a strong presumably sound static type system). That's a totally valid preference on your part. I like languages with rich type systems too, sometimes.

But I don't like them all the time, and you'd have a hard time arguing that they're universally objectively better than dynamic languages or optionally-typed ones. I do think that Dart's dynamic + a little optional typing is a very good fit for the domain it's aiming for: client-side (and front-end server-side) web development.

- bob

[wiltonlazary]

We have Ruby Groovy and Scala, i think that Dart have very old fashion
and Groovy is more modern and well tested language for Dart be based.

On 13 out, 15:48, Bob Nystrom <rnyst...@google.com> wrote:

> But I don't like them *all* the time, and you'd have a hard time arguing

> that they're universally objectively better than dynamic languages or

> optionally-typed ones. I *do* think that Dart's dynamic + a little optional

[Daniel]

Before getting off too far into the weeds, read my follow-up post. My
point isn't that it doesn't contain feature X, but that it doesn't
seem to innovate in any way at all, and instead takes the well-
trodden, and frequently loathed/discredited path. Creating a new
language is a precious opportunity to make programming easier/better/
more efficient. Just wondering why this opportunity seems to be missed
so far.

On Oct 13, 1:48 pm, Bob Nystrom <rnyst...@google.com> wrote:

> But I don't like them *all* the time, and you'd have a hard time arguing

> that they're universally objectively better than dynamic languages or

> optionally-typed ones. I *do* think that Dart's dynamic + a little optional

[Rémi Forax]

On 10/13/2011 08:48 PM, Bob Nystrom wrote:

3. type inference

Dynamic languages don't need type inference. :) Dart does have an optional type system but it's mostly a dynamic language.

I disagree, you can have inference and a dynamic language.
Take this example:

Map<String, Dynamic> m = {
    'one': new Partridge(),
    'two': new TurtleDove()
};

is equivalent to:

Map<String, Dynamic> m = <Dynamic, Dynamic> {
    'one': new Partridge(),
    'two': new TurtleDove()
};

With type inference it could be equal to the more natural:

Map<String, Dynamic> m = <String, Bird> {
    'one': new Partridge(),
    'two': new TurtleDove()
};

Rémi

[Damien Pollet]

On 13 October 2011 21:03, Rémi Forax <fo...@univ-mlv.fr> wrote:
> With type inference it could be equal to the more natural:
>
> Map<String, Dynamic> m = <String, Bird> {
> 'one': new Partridge(),
> 'two': new TurtleDove()
> };

But maybe you meant m to be a list of Animals, and it's only a
coincidence that the initialization value only has Birds.
Sure, the compiler could guess, but than means that sometimes it'll be
wrong, and if you want zero warning, you'll have to declare types
explicitly in some cases but not always, depending on what the actual
initialization happens to be.

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

[Szymon Stanisławowicz]

>
> Dart isn't intended to be an experimental academic language.
>

noncorporate nonproffesionals ;) also use javascript, make web pages,
etc. I think mere mortals wants some more nice stuff in js
replacement, not less ;) We ordinary people were using toy languages
(on toy machines) like logo, forth (and basic...) -- later in 90's
perl, lisp (toy "newlisp" dialect was/is hilarious stupid language,
but "little lisper", book for "kids" was amazing). Some lucky bastards
had access to smalltalk (I have seen as kid movie on which US kids
played with it. Smalltalk is wonderful toy. I almost cried ;) I would
prefer toy like javascript is. Not Dart. In JS with joose it's easy to
do "serious" object-oriented stuff. CoffeeScript is nice toy,
promising one imho.

The OP's point IMHO is not in "experimental academic" but "not very
conservative". Dart is too conservative ant too java-like for my
personal taste. ADA will have some nice stuff next year, and this is
rather "conservative" language ;)

Of course i see good stuff in Dart, however java-like (syntax and
flavor of object system) language is not thing i'm going to use (if i
will have any choice).

I want to wish you luck, but I shouldn't. JS is very, very far from
ideal but still it's better for me and some people I know (only three
of them are corporate guys, and two out of that three writes in non-
java languages... ;).

Regards.

PS. i'm not going to pollute your group anymore ;)

[Bob Nystrom]

On Thu, Oct 13, 2011 at 12:03 PM, Daniel <daniel...@gmail.com> wrote:

instead takes the well-trodden, and frequently loathed/discredited path.

Every language is loathed and discredited by some people, but you do have to acknowledge that the path is well-trodden. Maybe I'm overly optimistic but I'd like to think the people walking down the past weren't all idiots, so maybe some of the loathing and discrediting is a bit overblown.

 

Creating a new language is a precious opportunity to make programming easier/better/
more efficient.

I understand exactly where you're coming from. That is definitely our goal. We want to make the most amazing awesome powerful language we can. But you have to build that in the context of who you're making it more powerful for.

One path is to make the most brilliant language you can regardless of how different that makes it and how much it breaks from the past. The small number of people that are willing to jump across that break will be in a language that's easier/better/more efficient. But a lot of people won't make that jump because it's too different. (You may say that that's a personal fault of them, so they get what they deserve, but I'd like to be more inclusive then that.)

Another path is to make a language that's an improvement while being familiar enough to make that transition easier. Maybe the language won't be as amazing as it could hypothetically be, but more people will be comfortable using it.

Of course, the ideal goal is an super amazing language that is also somehow completely familiar, but at some point you start having to make some trade-offs. I really like that Dart is trying to be as inclusive as possible. The world doesn't need more incredible languages for people at the upper end of the bell curve. We've already got Scheme and Haskell. I think what it does need is a language that can help the millions of programmers that are currently writing Java and JavaScript and are struggling to push those languages beyond what they were designed for.

I also think Dart is a little more innovative than it first seems. Hiding under that syntax are some pretty cool ideas. The challenge is that many of them aren't apparent until you've written a good chunk of code, or until someone who has spends time explaining it. In the absence of the former, I and others are trying to do the latter, but that takes time.

It really does shave off a lot of pain points that many mainstream languages have, and I have a lot of confidence that the designers will continue to improve it. It's easy to overlook much of it because it's not sexy, but even simple stuff like this:

// Interface for a thing with a name.

interface Nameable {

  String get name(); 

}

class Person implements Nameable {

  String name; // Can implement a getter in an interface with a field.

}

is something that you can't do in Java or C#. (C# added auto properties and is gradually going in the direction of hiding fields. Dart is already there completely.)

There's a lot of these little improvements that make the day-to-day job of using Dart a little more pleasant than other languages I've worked in, and we're just getting started.

- bob

[Josh Leverette]

I just finished reading through this topic, and I'm seriously
disappointed. If you want to whine, then whine, but don't call it a
criticism of noninnovation. Dart is innovative. The ease of use of
anonymous functions and the new => incarnation of anonymous functions
is excellent. The string interpolation is a feature not found in very
many other places and is very useful and makes working with strings
fundamentally easier. The isolates have the potential to provide very
similar cross-computer concurrency and communication. The simplified
constructors have made me quite happy. I don't fully understand
factory constructors yet, but that's because I've never seen them in
the other languages I use. Including operator overloading in a web
scripting language is very potent. Yes, perhaps you could do all these
features using clever javascript libraries and enough elbowgrease, but
that's not these are only some of the benefits. Dart code will run
much faster than JavaScript once it gets fully implemented, and people
don't need extreme innovation to improve other people's lives. The
innovation in Dart is in its simplicity and its solid design. The fact
that features that are worth having are included and most of the cruft
is excluded. It isn't perfect, I have some complaints about it, but
those have largely been addressed by the gracious staff at Google who
is taking time to answer our petty complaints. I'm certain that
they've argued internally about almost every bit of 'innovation'
listed above, and unless you have some very compelling use cases for
that stuff they have already come to conclusive evidence not to do it.
Dart is innovative, but it's not wasteful, and it is elegant in
numerous ways.

I believe that Google will succeed in maximizing this product's
potential, and that is a good thing. I don't necessarily agree with
Google on a number of their policies, but as long as Dart remains open
source enough that I can fork it at any time, I believe it will be a
good thing. If it ever becomes proprietary to Google, then the
worrying might begin. All that remains is for the browser community to
be receptive to Dart, in which case it will always have a home for
many years to come even if Google were to do something horrendous to
it, thanks to the open source community's willingness to help out in
times like those, such as LibreOffice.

Do you have an actual complaint? Provide a use case where it's
problematic, and something needs to change. It may not be changed, but
it's much more likely than when you propose old concepts as innovative
and insult Dart and the people who designed it.. just saying.

-- a programmer of half a dozen years, programming & scripting
languages, and as many platforms, currently preferring Ubuntu Linux as
his primary OS, located in the Southeast of the US.

On Oct 13, 4:06 pm, Bob Nystrom <rnyst...@google.com> wrote:

> On Thu, Oct 13, 2011 at 12:03 PM, Daniel <danieldel...@gmail.com> wrote:
> > instead takes the well-trodden, and frequently loathed/discredited path.
>
> Every language is loathed and discredited by some people, but you do have to

> acknowledge that the path *is* well-trodden. Maybe I'm overly optimistic but

> I'd like to think the people walking down the past weren't all idiots, so
> maybe some of the loathing and discrediting is a bit overblown.
>
> > Creating a new language is a precious opportunity to make programming
> > easier/better/
> > more efficient.
>

> I understand exactly where you're coming from. That *is* definitely our

> goal. We want to make the most amazing awesome powerful language we can. But

> you have to build that in the context of *who* you're making it more

> powerful for.
>
> One path is to make the most brilliant language you can regardless of how
> different that makes it and how much it breaks from the past. The small
> number of people that are willing to jump across that break will be in a
> language that's easier/better/more efficient. But a lot of people won't make
> that jump because it's too different. (You may say that that's a personal
> fault of them, so they get what they deserve, but I'd like to be more
> inclusive then that.)
>
> Another path is to make a language that's an improvement while being
> familiar enough to make that transition easier. Maybe the language won't be
> as amazing as it could hypothetically be, but more people will be
> comfortable using it.
>
> Of course, the ideal goal is an super amazing language that is also somehow
> completely familiar, but at some point you start having to make some
> trade-offs. I really like that Dart is trying to be as inclusive as
> possible. The world doesn't need more incredible languages for people at the
> upper end of the bell curve. We've already got Scheme and Haskell. I think

> what it *does* need is a language that can help the millions of programmers

[Josh Leverette]

"but that's not these are only" typos for the win. I wonder why there
is no way to edit a post at all, even if the emails don't get updated.
Obviously this statement was supposed to say "but these are only"

[Colin Putney]

On Thu, Oct 13, 2011 at 1:06 PM, Bob Nystrom <rnys...@google.com> wrote:

> Another path is to make a language that's an improvement while being
> familiar enough to make that transition easier. Maybe the language won't be
> as amazing as it could hypothetically be, but more people will be
> comfortable using it.

I think another under-appreciated goal is the "from quick prototypes
to serious apps." There aren't many languages out there that are
designed to scale conceptually as well as practically. Javascript and
PHP are good examples of languages that are very approachable. It's
easy to add a bit of Javascript to a web page to get a bit of dynamic
behaviour on the client, and PHP is similarly easy to get going with
on the server side. The barrier to entry is incredibly low - just add
a special tag with a few lines of code and you're off. But as you
start doing more with the language, and the size of your team and code
base grows it becomes difficult to manage complexity in these
languages. It can be done, and there are some famous examples, but it
takes a lot of discipline and you end up fighting the language a lot.

On the other end of the continuum you have languages like Java, C# and
even Smalltalk. They're designed to be usable at scale by large teams
with large codebases and solving complex problems. They have features
that help manage that complexity, encourage communication between
developers, and allow kinds of tools that large projects need. But
these languages don't scale *down* very well, and they're not at all
approachable. Setting up a development environment is a lot of work
and involves a lot of moving parts. Deployment is even more difficult.

Most languages fall in between the two extremes, of course. What I
love about Dart is that it aims to be a language that truly scales on
this continuum. It won't be simple, and we're a long way of knowing if
they Dart team will be able to pull it off. But it's a really valuable
goal, and I think they've made some design choices in subtle ways that
we don't full appreciate yet.

Colin

[Luke Church]

4. significant indentation (vs. a slurry of curly braces)

Incidentally, this is a pretty serious source of errors for novice programmers. 

I think it's fair to say that the weight of evidence of user studies that I've seen is calling against significant whitespace. As is the relevant predicting cog. science theory. It could be that if it wasn't for the tabs/spaces distinction this would be less of an issue, but until I see data to the contrary I'm going to have to go with current UX evidence being in favor of braces + tool support.

[Daniel]

I wouldn't call these complaints. Reading through the docs, I just
became curious why Dart follows the well-traveled path, even in cases
where newer paths have proven more concise (type inference), safer
(immutability by default), more readable (whitespace significant), or
more productive (pattern matching). These are examples of somewhat non-
traditional (arguably innovative) features, not a wish list. I was
merely probing for reasons behind the design choices. Bob's answer, I
think, offers some good explanations.

On Oct 13, 3:45 pm, Josh Leverette <coder...@gmail.com> wrote:

[Daniel]

I wouldn't say it's "fair" until you've cited these studies. :-)

Tangentially, code is written mostly to be read.

[John Tamplin]

On Thu, Oct 13, 2011 at 5:56 PM, Daniel <daniel...@gmail.com> wrote:

Tangentially, code is written mostly to be read.

And different people have different ideas about what constitutes the most readable code -- for me I find Dart style to be easier to read than python/Coffeescript/etc.  Certainly familiarity enters into it, but then I suspect more programmer hours have been spent cumulatively this year in languages with braces (C, C++, C#, Java, JS, ...) than in those with significant whitespace.

I get that you don't like it and if you were in charge you would choose to use significant whitespace, but other people would (and did) choose differently.

[rob]

I'm in agreement with you, Johm, that C-like languages are easier to
look at, but more importantly, that having similar syntax to
javascript is a highly pragmatic decision -- and therefore the *right*
decision, given the huge hurdle you will have getting people to switch
from something they have familiarity with, and that there is huge
amounts of existing code in.

Ability to paste in (or otherwise integrate) javascript code is a HUGE
thing. Language geeks may not care about it, but people who work in
the real world do.

So yeah, please stick with braces.

On Oct 13, 3:05 pm, John Tamplin <j...@google.com> wrote:

[Michael V]

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

... seems like a pretty good way to weight how the next-big-language
is supposed to 'feel'.

[Bruce Williams]

Maybe, but may simply be "making the most of a bad situation" 

Bruce Williams 
------------------------------------------------------------------------
Concepts, like individuals, have their histories and are just as incapable
of withstanding the ravages of time as are individuals. 

But in and through all this they retain a kind of homesickness 
for the scenes of their childhood.  

Soren Kierkegaard  

[Florian Bösch]

On Oct 13, 11:11 pm, Luke Church <lukechu...@google.com> wrote:
> Incidentally, this is a pretty serious source of errors for novice
> programmers.
>
> I think it's fair to say that the weight of evidence of user studies that
> I've seen is calling against significant whitespace. As is
> the relevant predicting cog. science theory. It could be that if it wasn't
> for the tabs/spaces distinction this would be less of an issue, but until I
> see data to the contrary I'm going to have to go with current UX evidence
> being in favor of braces + tool support.

Don't quote some statistic without paper, or it didn't happen.

You're measuring the usability of significant whitespaces solely on
their suitability for editors of users incapable of using their
settings dialog, reading any guidance and which are novices. That's a
flawed point of view.

Significant whitespaces are beneficial in a number of areas:
- readability [improved]
- terseness [increased]
- no structure/indent missmatch [avoided]

In languages with non-significant whitespaces where additional syntax
is used each of those has a cost, which can be quite high.
- readability [retarded]: code is more often read then written, high
cost
- terseness [bloated]: long code is far more difficult to maintain
even if it is functionally identical to shorter code (note this is not
an excuse for substituting good programming construct with white
noise, like Perl)
- structure indent missmatch [debug horror]: cost of this can be
extremely high, especially in team environments.

[Peter]

On Oct 14, 5:06 am, Bob Nystrom <rnyst...@google.com> wrote:
> We want to make the most amazing awesome powerful language we can. But

> you have to build that in the context of *who* you're making it more

> powerful for.
>
> One path is to make the most brilliant language you can regardless of how
> different that makes it and how much it breaks from the past. The small
> number of people that are willing to jump across that break will be in a
> language that's easier/better/more efficient. But a lot of people won't make
> that jump because it's too different. (You may say that that's a personal
> fault of them, so they get what they deserve, but I'd like to be more
> inclusive then that.)
>
> Another path is to make a language that's an improvement while being
> familiar enough to make that transition easier. Maybe the language won't be
> as amazing as it could hypothetically be, but more people will be
> comfortable using it.
>

> ... I really like that Dart is trying to be as inclusive as

> possible. The world doesn't need more incredible languages for people at the
> upper end of the bell curve. We've already got Scheme and Haskell. I think

> what it *does* need is a language that can help the millions of programmers

> that are currently writing Java and JavaScript and are struggling to push
> those languages beyond what they were designed for.
>
> I also think Dart is a little more innovative than it first seems. Hiding
> under that syntax are some pretty cool ideas. The challenge is that many of

> them aren't apparent until you've written a good chunk of code....

>
> It really does shave off a lot of pain points that many mainstream languages
> have, and I have a lot of confidence that the designers will continue to

> improve it....

Well said!

People should be forced to read that before writing yet another, "Dart
sucks. It should be more like Haskell." post.

[Michael Hendricks]

On Thu, Oct 13, 2011 at 3:54 PM, Daniel <daniel...@gmail.com> wrote:

safer (immutability by default)

This is an interesting candidate for large scale JavaScript analysis.  What percentage of local JavaScript variables in the wild are ever mutated? If the percentage is small maybe immutability should be the default.

-- 

Michael 

[Dirk Detering]

Dart looks interesting an promising. But to gain more attraction in a time where FP and immutability gets more and more attention (and JS indeed being somehow functional), it is absolutely disappointing to find in the samples code with bunches of   void xxx () - methods communicating over member variables. Globals are out, even inside a class, where possible.

http://code.google.com/p/dart/source/browse/trunk/dart/samples/socket/SocketExample.dart