Ensuring continued innovation in Dart. Or: where are the roadmap & vision statement?
Patrice Chalin
Among the most appealing aspects of Dart, to me, are its concise yet expressive notation, and (relatively) clean and simple semantics. Dart is to JS what Scala is to Java in the sense that: Dart is a state-of-the-art fielded language (used in sizable production code) making available today features that are quite likely to be retroactively adopted in subsequent releases of Java/TypeScript (metadata is one example that has already happened, thanks in part to the needs of Angular).
I would love to see the evolution of Dart fueled by exciting new features while remaining grounded/pragmatic, and preserving its core qualities. But that raises the question: what are the core defining qualities of Dart? What’s the elevator pitch?
IMHO, Dart needs a concise vision statement to capture its core defining qualities. Such a vision can help direct innovation (so that we can be proactive in proposing pioneering features) and provide a high level yay/nay test against which any new DEP can be assessed (based on whether it supports the vision or not). The formulated vision can also help the language design team ensure that Dart can clearly “stand out” (as Kasper put it) from the larger and rapidly changing ecosphere of scalable web/server/mobile app technologies. (E.g., how will Dart be positioning itself against new players like Scala.js --- which, e.g., already offers preliminary Angular support via scalajs-angular? :)
IMHO, Dart also needs to have a complete list of language features that are being considered. Having such a list is an essential prerequisite to doing feature baselining. A quick review of the list would also allow one to ensure that there is a proper balance of innovative vs. (more mundane but essential) housekeeping features. Driven by the vision, this list needs to include the significant core features that are planned for Dart in the medium to long term, e.g., to suggest a few:
Union types? (Intersection types?)
(Deeply) immutable / value types (issue #501).
With the former, why not fully embrace functional programming (FP)? I believe that Dart, like Scala, is a good candidate to offer “the best of [OOP & FP] worlds” (as is touted on the Scala home page). FP and immutable types will prove invaluable for, e.g., Angular and Angular apps.
What are the implications of the advent of the DDC’s strong mode? Does this mean that there will be (subtly) different type systems for Dart? Maybe it’s time to formalize Gilad’s vision of a pluggable type system for Dart? We need a unified semantic foundation for Dart’s type system (basic, strong mode and maybe other variants). While this concerns semantic foundations, it will invariably affect usability (e.g. developers need a clear understand of the relationship between strong mode and “normal mode”) and tooling.
Careful planning needs to be done for the (possibly stratified) introduction of sizable core features. This is all considerable work, but necessary if Dart is to maintain its lead (lest it risk becoming a rapidly obsolete "alternative to JS/TS").
A roadmap is the usual place to document a feature list. As examples of roadmaps, consider those for TypeScript and Scala 2.12 (the next release of Scala). The TS roadmap is a simple bulleted list. The Scala 2.12 roadmap is much more complete covering: Goals, How, Background, Shared features (between current release (under flags) and next release), Timing, and more. There is also a separate Scala roadmap for releases beyond the next (2.12) that are as yet unnumbered (hence it avoids being committal about feature timing --- i.e., 2.x or 3.x or beyond). For starters, it would be nice to see at least a simple bulleted-list roadmap for Dart.
I’m not aware of any vision statement or roadmap for Dart. If these exist, it would be useful to publish them as part of dart-lang/DEP repo. While it is nice to have a place for the community to submit DEPs, it would also be nice if the community could vote on individual features (a capability we used to have via dartbug.com when under Google Code).
Cheers,
Patrice
p.s. An interesting Scala feature being developed is the use of “typed (abstract syntax) trees” as an intermediate representation, instead of byte code, from which backends are targeting the JVM and JavaScript. Might Scala end up being serious competition for Dart?
p.p.s. Notice from Scala’s roadmap that the “Don Giovanni” release includes “simplifying foundations”, in particular with respect to the type system which is to be couched in a “minimal core calculus” named the: Dependent Object Types (DOT) system for Scala-like languages (Odersky et al. [1, 2]). Maybe a similar exercise is necessary for Dart?
Seth Ladd
Among the most appealing aspects of Dart, to me, are its concise yet expressive notation, and (relatively) clean and simple semantics. Dart is to JS what Scala is to Java in the sense that: Dart is a state-of-the-art fielded language (used in sizable production code) making available today features that are quite likely to be retroactively adopted in subsequent releases of Java/TypeScript (metadata is one example that has already happened, thanks in part to the needs of Angular).
I would love to see the evolution of Dart fueled by exciting new features while remaining grounded/pragmatic, and preserving its core qualities. But that raises the question: what are the core defining qualities of Dart? What’s the elevator pitch?
IMHO, Dart needs a concise vision statement to capture its core defining qualities.
Such a vision can help direct innovation (so that we can be proactive in proposing pioneering features) and provide a high level yay/nay test against which any new DEP can be assessed (based on whether it supports the vision or not). The formulated vision can also help the language design team ensure that Dart can clearly “stand out” (as Kasper put it) from the larger and rapidly changing ecosphere of scalable web/server/mobile app technologies. (E.g., how will Dart be positioning itself against new players like Scala.js --- which, e.g., already offers preliminary Angular support via scalajs-angular? :)
IMHO, Dart also needs to have a complete list of language features that are being considered. Having such a list is an essential prerequisite to doing feature baselining. A quick review of the list would also allow one to ensure that there is a proper balance of innovative vs. (more mundane but essential) housekeeping features.
Driven by the vision, this list needs to include the significant core features that are planned for Dart in the medium to long term, e.g., to suggest a few:
Union types? (Intersection types?)
(Deeply) immutable / value types (issue #501).
With the former, why not fully embrace functional programming (FP)? I believe that Dart, like Scala, is a good candidate to offer “the best of [OOP & FP] worlds” (as is touted on the Scala home page). FP and immutable types will prove invaluable for, e.g., Angular and Angular apps.
What are the implications of the advent of the DDC’s strong mode? Does this mean that there will be (subtly) different type systems for Dart? Maybe it’s time to formalize Gilad’s vision of a pluggable type system for Dart? We need a unified semantic foundation for Dart’s type system (basic, strong mode and maybe other variants). While this concerns semantic foundations, it will invariably affect usability (e.g. developers need a clear understand of the relationship between strong mode and “normal mode”) and tooling.
Careful planning needs to be done for the (possibly stratified) introduction of sizable core features. This is all considerable work, but necessary if Dart is to maintain its lead (lest it risk becoming a rapidly obsolete "alternative to JS/TS").
A roadmap is the usual place to document a feature list. As examples of roadmaps, consider those for TypeScript and Scala 2.12 (the next release of Scala). The TS roadmap is a simple bulleted list. The Scala 2.12 roadmap is much more complete covering: Goals, How, Background, Shared features (between current release (under flags) and next release), Timing, and more. There is also a separate Scala roadmap for releases beyond the next (2.12) that are as yet unnumbered (hence it avoids being committal about feature timing --- i.e., 2.x or 3.x or beyond). For starters, it would be nice to see at least a simple bulleted-list roadmap for Dart.
I’m not aware of any vision statement or roadmap for Dart. If these exist, it would be useful to publish them as part of dart-lang/DEP repo. While it is nice to have a place for the community to submit DEPs, it would also be nice if the community could vote on individual features (a capability we used to have via dartbug.com when under Google Code).
Cheers,
Patrice
p.s. An interesting Scala feature being developed is the use of “typed (abstract syntax) trees” as an intermediate representation, instead of byte code, from which backends are targeting the JVM and JavaScript. Might Scala end up being serious competition for Dart?
p.p.s. Notice from Scala’s roadmap that the “Don Giovanni” release includes “simplifying foundations”, in particular with respect to the type system which is to be couched in a “minimal core calculus” named the: Dependent Object Types (DOT) system for Scala-like languages (Odersky et al. [1, 2]). Maybe a similar exercise is necessary for Dart?
--
You received this message because you are subscribed to the Google Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.
Günter Zöchbauer
Bob Nystrom
Glad you asked! :) We've started a project to build a new website for Dart, which we hope will make it very clear what Dart is to developers in 2016 and beyond.
Seth Ladd
Cheers!- bob
Patrice Chalin
... equally important for the Dart team itself to have a shared vision for the direction of the project. Otherwise, we can end up all pulling in different directions and going nowhere.
We're starting to talk about what "Dart 2.0" means, and I hope out of the outcomes of that is a clearer picture for what kind of language we want Dart to be, and that we can all agree on that picture.
Warren Strange
Bob Nystrom
We're starting to talk about what "Dart 2.0" means, and I hope out of the outcomes of that is a clearer picture for what kind of language we want Dart to be, and that we can all agree on that picture.I assume that the committee is juggling with _some_ list of features.
Patrice Chalin
TL;DR: Writing everything down is surprisingly hard.
Patrice Chalin
I am all for having a shared and public vision for Dart. We have iterated on one internally and I think it's time to develop one for the whole Dart team which matches well with the current state and which we can also share broadly and point people interested in Dart to. As Seth said, this is going to be on the new homepage.
We are not going to have a detailed roadmap of which features are going into which release. That is not how we operate. We do have a list, though, of high level features that we are actively working on and are hoping to land in the next stable release. I think it would be fine to communicate what this list looks like. Also, while this is not a roadmap in and of itself, the list of current DEPs gives you a good idea about what is being considered and what we expect to actively work on.
Anders Sandholm
Bob Nystrom
Here is a concrete example. While I think DEP 30 (non-null types) is a good idea :) ... IMHO resources would be better spent realizing union types first since (again, in my opinion), the overall effort of implementing non-null types before union types is greater (and potentially more risky) than doing it the other way around. (It is more risky because, e.g., an incongruence between non-null types and union types might inadvertently be introduced while implementing non-null types; then one must choose between introducing a breaking change vs. living with the incongruity).
Here is an another example. Responsive client-side apps (built using, say, Angular), and concurrent programming in general, can greatly benefit from value types. Yes, it is a complex issue, as Gilad has pointed out in a comment to issue #501, but it is an important one. Then again, value types and broader support for functional programming (FP) go nicely together. Are either of these being considered? (Value types are even being considered for Java 9! ;) ... here is the 20 page proposal).
Yes, value types come up pretty frequently in discussions, though it isn't always clear that we all agree on what "value types" even means. To me, it's about controlling allocation (value types are on the stack or directly embedded in objects). To others, it's about deep immutability.
Erik Ernst
On Fri, Aug 28, 2015 at 6:43 AM, Patrice Chalin <pch...@gmail.com> wrote:
[.. order of NNBD & union types ..][..] Non-nullable types will be a big complex piece of machinery to land, so I expect there will be lots of time [..]Here is an another example. [..] value types. [..]
Yes, value types come up pretty frequently in discussions, though it isn't always clear that we all agree on what "value types" even means. To me, it's about controlling allocation (value types are on the stack or directly embedded in objects). To others, it's about deep immutability.
Patrice Chalin
... To me, it's about a conceptually robust notion of values, and a corresponding language semantics in the support for that concept.... With that, small-space value types (<= 8 bytes or so) could be copied freely and passed in registers etc. (which is a typical expectation for value types), but we would also have a consistent semantics for values whose memory representation is larger (they can freely be shared, partially shared, copied, marshalled/unmarshalled and communicated in distributed systems, etc.).
Bob Nystrom
Yes, value types come up pretty frequently in discussions, though it isn't always clear that we all agree on what "value types" even means. To me, it's about controlling allocation (value types are on the stack or directly embedded in objects). To others, it's about deep immutability.Can't resist adding a different perspective to this: To me, it's about a conceptually robust notion of values, and a corresponding language semantics in the support for that concept.So values may be simple or composite, but the representation must be kept immutable at all times and it must be referentially transparent. You may or may not refer to the representation via a pointer, but you can't tell, and you can never tell the difference between the case where "the same value" is the same representation in memory, e.g., in the same register or reached via the same pointer value, or two different representations of the same value, which may or may not be represented using the same bits in different memory locations (a representation which is built from several heap entities would already violate that expectation, because internal pointers among them would be different as bit strings, but the graphs constituted by those entities would be isomorphic). Of course, equality among values is structural, which should be supported and enforced by the language (but that's inevitable given that we require referential transparency).With that, small-space value types (<= 8 bytes or so) could be copied freely and passed in registers etc. (which is a typical expectation for value types), but we would also have a consistent semantics for values whose memory representation is larger (they can freely be shared, partially shared, copied, marshalled/unmarshalled and communicated in distributed systems, etc.).
Yup, this is more or less what I had in mind with "deep immutability". Once you have that, it's no longer visible whether or not an object is passed by value (copied) or by reference, so an implementation is free to do whichever it prefers.
Erik Ernst
Erik Ernst
On Mon, Aug 31, 2015 at 1:00 AM, Erik Ernst <eer...@google.com> wrote:
Yes, value types come up pretty frequently in discussions, though it isn't always clear that we all agree on what "value types" even means. To me, it's about controlling allocation (value types are on the stack or directly embedded in objects). To others, it's about deep immutability.Can't resist adding a different perspective to this: To me, it's about a conceptually robust notion of values, and a corresponding language semantics in the support for that concept.
So values may be simple or composite, but [..] immutable [..] referentially transparent.[..] graphs constituted by those entities would be isomorphic [..] equality among values is structural [..][..] value [..] could be copied freely and passed in registers etc. [..] also have a consistent semantics for values whose memory representation is larger [..]
Yup, this is more or less what I had in mind with "deep immutability". Once you have that, it's no longer visible whether or not an object is passed by value (copied) or by reference, so an implementation is free to do whichever it prefers.
Where it gets tricky is equality. For the above to be true, you do need full referential transparency like you say. That in turn implies structural equality such that you can't distinguish between objects with the same state even if they came from different provenance.
I appreciate the appeal of this from a theoretical standpoint, but it's not what I think Dart needs. If our goal is to be an efficient client-side language, I think controlling allocation is critical.
This has always been one of the big advantages of C, C++, C#, and Go. Java and JavaScript in contrast really struggle.
If you look at, for example, the Android APIs, you can see where they have worked very hard to minimize allocations in spite of what Java gives them, and JS goes through similar machinations.
Bob Nystrom
If you look at, for example, the Android APIs, you can see where they have worked very hard to minimize allocations in spite of what Java gives them, and JS goes through similar machinations.I actually think that it all starts with the consistent and well-understood semantics.
As soon as you have that I'm sure you can use it to provide a very well performing `int` etc.,
and then the language as a whole would still be comprehensible (as opposed to the mess they have in Java where object identity causes confusing properties of various types that-should-have-been-value-types).
Yeah, I think Java made a few mistakes here. I don't think that strictly implies that all possible approaches in that area are doomed to failure. Go and C# also have controlled-allocation value types and they seem to work OK in both places.
Patrice Chalin
... There's no silver bullet, of course, but the set of language features you expose does have an affect on performance.
Seth Ladd
Bob Nystrom
Dart 1.0 was, IMHO, enthusiastically received because it addressed a pressing need: maintaining sizable JS apps was becoming overbearingly painful. As we know, JS was never intended to be a language for engineering large software systems. Dart addressed this need by offering proper encapsulation mechanisms in an expressive yet simple language.
As discussions of Dart 2.0 are picking up, I can't help but be reminded of the warnings of Frederick Brooks about the second-system effect: "when embarking on a second [version of a] system, an engineer should be mindful that they are susceptible to over-engineering it." If Dart has too broad a mandate it runs the risk of becoming yet a(n other) bloated language, or on the flip side, not quite fully satisfying the needs of any of its intended uses. While we know that language design is about balance, my hope that there isn't an attempt to balance too much in one go. My 2 cents.
I agree totally. I think the most important decisions we can make for Dart 2.0 are what not to do.
Patrice Chalin
I think one of our biggest problems is that Dart hasn't been enthusiastically received, at least not externally. Inside Google, we're really happy with the language's growth, but our external userbase isn't where it needs to be yet.
I agree totally. I think the most important decisions we can make for Dart 2.0 are what not to do.
Benjamin Strauß
On Wed, Sep 2, 2015 at 10:13 AM, Patrice Chalin <pch...@gmail.com> wrote:Dart 1.0 was, IMHO, enthusiastically received because it addressed a pressing need: maintaining sizable JS apps was becoming overbearingly painful. As we know, JS was never intended to be a language for engineering large software systems. Dart addressed this need by offering proper encapsulation mechanisms in an expressive yet simple language.I think one of our biggest problems is that Dart hasn't been enthusiastically received, at least not externally. Inside Google, we're really happy with the language's growth, but our external userbase isn't where it needs to be yet.
