Monday, October 10, 2011

Google unveils the brand new programming language 'Dart'

Dart is a new class-based programming language for creating structured web applications. Developed with the goals of simplicity, efficiency, and scalability, the Dart language combines powerful new language features with familiar language constructs into a clear, readable syntax.


Key features
Key features of the Dart language include:
Classes
Classes and interfaces provide a well understood mechanism for efficiently defining APIs. These constructs enable encapsulation and reuse of methods and data.
Optional types
Dart programmers can optionally add static types to their code. Depending on programmer preference and stage of application development, the code can migrate from a simple, untyped experimental prototype to a complex, modular application with typing. Because types state programmer intent, less documentation is required to explain what is happening in the code, and type-checking tools can be used for debugging.
Libraries
Developers can create and use libraries that are guaranteed not to change during runtime. Independently developed pieces of code can therefore rely on shared libraries.
Tooling
Dart will include a rich set of execution environments, libraries, and development tools built to support the language. These tools will enable productive and dynamic development, including edit-and-continue debugging and beyond up to a style where you program an application outline, run it, and fill in the blanks as you run.
Design goals
The Dart programming language is presented here in its early stages. The following design goals will guide the continued evolution and refinement of this open source project:
Create a structured yet flexible programming language for the web.
Make Dart feel familiar and natural to programmers and thus easy to learn.
Ensure that all Dart language constructs allow high performance and fast application startup.
Make Dart appropriate for the full range of devices on the web including phones, tablets, laptops, and servers.

Provide tools that make Dart run fast across all major modern browsers.
These design goals address the following problems currently facing web developers:
Small scripts often evolve into large web applications with no apparent structure they are hard to debug and difficult to maintain. In addition, these monolithic apps can t be split up so that different teams can work on them independently. It s difficult to be productive when a web application gets large.

Scripting languages are popular because their lightweight nature makes it easy to write code quickly. Generally, the contracts with other parts of an application are conveyed in comments rather than in the language structure itself. As a result, it s difficult for someone other than the author to read and maintain a particular piece of code.
With existing languages, the developer is forced to make a choice between static and dynamic languages. Traditional static languages require heavyweight toolchains and a coding style that can feel inflexible and overly constrained.
Developers have not been able to create homogeneous systems that encompass both client and server, except for a few cases such as Node.js and Google Web Toolkit (GWT).
Different languages and formats entail context switches that are cumbersome and add complexity to the coding process.

Optional types
Dart provides, at the programmers option, a mixture of static and dynamic checking. When experimenting, the programmer can write untyped code for simple prototyping. As the application becomes larger and more stable, types can be added to aid debugging and impose structure where desired.

You will be able to run Dart code in several ways:
Translate Dart code to JavaScript that can run in any modern browser:
Chrome, Safari 5+, and Firefox 4+ (more browser support coming shortly).
Execute Dart code directly in a VM on the server side
Use Dartboard to write, modify, and execute small Dart programs within any browser window
The Dart language is dynamically typed. You can write programs that have no type annotations whatsoever, and run them, much as you would in JavaScript.

You may choose to add type annotations to your program:
Adding types will not prevent your program from compiling and running even if your annotations are incomplete or plain wrong.
Your program will have exactly the same semantics no matter what type annotations you add.
You can nevertheless profit from adding type annotations to your code. Types provide the following benefits:
Documentation for humans. It is much easier for people to read your code if it has judiciously placed type annotations.
Documentation for machines. Tools can leverage type annotations in various ways. In particular, they can help provide nice features such as name completion and improved navigation in IDEs.
Early error detection. Dart provides a static checker that can warn you about potential problems, without getting in your way. In addition, in developer mode, Dart automatically converts type annotations to runtime assertion checks as a debugging aid.
Sometimes, types can help improve performance when compiling to JavaScript. Well say more about this later.
The static checker acts a lot like lint in C. It warns you about potential problems at compile-time. Many of these warnings are related to types. The static checker does not produce errorsyou can always compile and run your code, no matter what the checker says.
The checker does not scream about every possible type violation. It is not a typechecker, because Dart doesnt use types the way a classic type system does. The checker complains about things that are very likely to be real problems, rather than forcing you to jump through hoops to satisfy a narrow-minded type system.
Dart supports reified generics. That is, objects of generic type carry their type arguments with them at run time. Passing type arguments to a constructor of a generic type is a runtime operation. How does this square with the claim that types are optional?
Well, if you dont want to ever think about types, generics wont force you to. You can create instances of generic classes without providing type parameters.
Dart programs can be run in checked mode during development. If you run a program in checked mode, the system will automatically execute certain type checks when passing in parameters, when returning results, and when executing assignments. If the checks fail, execution will stop at that point with a clear error message.
How you use types is up to you. If you hate types, you need not use them at all. You wont get any type warnings, and you can develop in the style you feel comfortable with in other dynamic languages. You can still benefit from types, because the Dart libraries have type signatures that tell you what they expect and what they return. If you run in checked mode, and pass bad arguments to the library, checked mode will detect that at the point where you made the mistake.
If you love types, you may use them everywhere, much like in a statically typed language. However, even then you wont get the same level of static checking. Darts rules are much less rigid. We anticipate providing additional tools that might interpret type annotations more strictly for those who like that sort of thing.
We dont recommend either of these extremes. Use types where they make sense. The most valuable thing you can do is add types to the headers of public members of your libraries. Next, do the same for the private ones. Even if nobody else has to maintain the code, you will find it helpful if you leave the code and come back in a few weeks or months. In both cases, you dont necessarily have to add types to the bodies of methods or functions. Users of the library get value from type signatures, even if they are not 100% accurate.
Within the bodies of functions, it may not always pay to annotate declarations. Sometimes the code is simple enough that it doesnt really matter, and types might just create clutter.
Usually, you should design your code without letting type considerations influence your design. In some cases, there are alternate designs, one of which plays better with types than another. For example, rather than passing around strings denoting function names to be invoked, if you can pass a function instead, your code will be both more efficient and easier to typecheck. Dart discourages gratuitous use of reflection by other means as well. However, you should not hesitate to use reflection when it truly makes sense.