Dart's the best programming language I've ever used

[Joao Pedrosa]

Hi,

I'd like to take a minute to praise Dart and the Dart team. Because it's good to feel gratitude. :-)

Rather than to just put words onto it, I've decided to create a mosaic of components I've been

able to work on. In part because Dart facilitated it. Some of the ideas I've used came before Dart

was around.

See:

http://s5.postimg.org/mf8nl01h3/dart_mosaic.png

The web has had a dearth of components for a long while. When I first found out about the web

way back when, one of the first things I tried to write was a component in JavaScript to display

a tree of collapsable items. It was the rage back then.

And so it was a story that started with client-side in Delphi, went to server-side with Ruby and

now back again on the client-side with Dart.

With both Java and JavaScript it was a lot of reading and watching but not enough hands-on.

In JavaScript we could stall at silent errors that killed execution at some point, but where?

In Ruby it was a bit of uncertainty regarding whether the variables have any typos, whether

I could trust the scope I was working on, and whether it was ever going to be fast enough.

Even then, I said that I loved Ruby. Because thought gave way to code, so easy to

experiment.

In Delphi it was fast all right. But then came .NET and the rats myself included abandoned

the ship. :-)

But what sets Dart apart? It's not because Dart includes all of that could be found elsewhere.

Compared with Delphi which had origins in Pascal, in Dart we can declare variables

everywhere, not just at the top of the function/procedure. Like Delphi/Pascal, Dart keeps

a small set instructions. Like Delphi, Dart is capable of producing a single package

for shipping purposes via "statically linking." :-)

Dart keeps some dynamism found in Ruby and JavaScript which makes prototyping

(see mosaic above) much easier. Like them, Dart also has anonymous functions with

closures. Which is to me one of Dart's important features. I learned to love closures with

those other languages. Say, if we can't have multiple returns from functions, we can at

least workaround that with functions and closures. Keep that in mind when the time 

presents itself.

Dart like some of its predecessors has been over-ambitious. Now it gets serious. Unlike

previous language attempts, Dart has had to support a variety of hardware and deployment

stories. Hardware ranging from "legacy" Intel to mobile ARM. And also has had to support

compilation to JavaScript so it can work on browsers without native Dart support.

At the very least instead of trying to support native GUI/UI of each platform like Java

attempted before it, Dart attaches itself to browsers for that. Browsers that differ from

one another but at least try to cooperate when possible.

Does the web need extra components though? To me it does. I like it when I go on a

chess site and can browse game moves using a web component. I like playing games

when I'm in the mood. Thanks Flash for that!

Is it easy to write web components? Not yet. I'm amazed when folks create text editors

using just DOM. Yesterday I came upon a text editor that supported tabs in a text area.

Folks go out of their way to find tricks to get what they want.

Technology used by web components is developing at an incredible pace. Canvas is now

more widespread. WebGL is being worked on. Mozilla have been improving Firefox a great

deal which helps with web components. In part it's because the web has been absorbing

what existed before it, like desktop programming and so on.

Why does it matter? Diversity in hardware and software makes it difficult to target each one

of them specifically. Having a common-ground in the web gets software into the hands of

users no matter whether they have a recent or legacy hardware. :-)

Dart is a downplayed language. Dart gives us an imperative language that has a more

regular, repetitive syntax and semantics. It may not be a language for the future like a

language to fix parallelism issues or programming errors, but it could well be a language

for the present so in the future we can port programs written in a structured Dart more

easily to some other ultimate/greatest language ever.

I can take a look at any one of my Dart files and they can look just like the latest one

I've been working on. That's regular. That's common-ground. If it works for the web, it might

as well work for a language targeting the web.

I hope it was not too long.

Thanks again!

Cheers,

Joao

[Si Robertson]

Dart is probably the best language available right now for browser based applications, but I certainly wouldn't call it the best language ever, there are better languages available for native applications etc. C, C++ and C# are the first that spring to mind.

Dart is very cool though, I'm using the VM for a browser based 3D game at the moment :-)

[Shailen Tuli]

Hi Joao, 

I am delighted that you find Dart so great! Here's an idea: why not make your message to the group a blog post? That way, you'll reach people who are not already familiar with Dart.  

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

--
Developer Programs Engineer (Dart)

Developer Relations

Google

developers.google.com

[john smith]

>> Here's an idea: why not make your message to the group a blog post? That way, you'll reach people who are not already familiar with Dart.

I think it is not worth it. At least in this form.

Too much is not substantive judgments.

Why Dart compared with Pascal but not with C# or Typescript?

Maybe it would be better to compare it with the Fortran language? Get much more convincing. But this fact alone does not give the charm of the article.

I think author need to be more objective rather than subjective.

[Joao Pedrosa]

Hi,

@Si Robertson: Nice. Keep up the good work! I hope to at some point give WebGL a try too. The learning curve is what scares me. :-)

@Shailen Tuli: I'll give that a think. I rushed this post a bit. Cheers.

@John Smith: I based it on my own experience. I haven't used either C# or TypeScript. C# is platform dependent (I used to run Linux more often) despite Mono efforts. TypeScript is a lot of JavaScript still, whereas Dart started anew and could do away with some of the bad stuff of JavaScript and make the syntax more regular. Comparisons with "==" rather than "===" for example.

Here's an analogy. Delphi was not a Microsoft technology, but it was good. Once Microsoft announced .NET, Delphi took a nose-dive. Replace Delphi with Dart and .NET with TypeScript in the previous sentence.

I'm not sure about Dart's fate yet. The good thing is that Dart gets compiled into JavaScript, so if JavaScript improves, so does Dart.

TypeScript apparently takes great pride in staying closer to the generated JavaScript. So it looks "nicer" if you're looking at keeping the JavaScript generated code more human-readable. On the other hand, that restricts what TypeScript can do for us. Dart has more freedom regarding the generated JavaScript. Benchmarks show that generated JavaScript from Dart is quite competitive with hand-crafted JavaScript, unless we were trying to extract 100% raw performance out of JavaScript, which to some large programs may be important. So Dart is not without critics to be sure.

Will I ever have to use TypeScript instead of Dart? That's a question for us all to answer.

Cheers,

Joao

--

[john smith]

>> Dart's the best programming language I've ever used

>> I based it on my own experience. I haven't used either C# or TypeScript.

Delphi generate output of binary data. Dart and Typescript can generate output language in Javascript language. But why compare output data but not the languages ​​themselves? Or you also want to compare later Javascript and binary data?

If you want write about language then write about it. Delphi and the NET Framework are not comparable as programming languages.

I understand you but I have not figured out from the your messages why the Dart is the best programming language for all programmers in world? Just because you do not have experience with other languages?

пятница, 26 июля 2013 г., 15:13:59 UTC+6 пользователь Joao Pedrosa написал:

[Joao Pedrosa]

Hi John,

I tried to write something to answer that. But it got long fast with more questions than answers. :-)

Let me instead focus on your questions.

>> Delphi generate output of binary data. Dart and Typescript can generate output language in Javascript language. But why compare output data but not the languages themselves? Or you also want to compare later Javascript and binary data?

Each language was built for a purpose at different times in history. Breaking with tradition has often been difficult. TypeScript is said to be a super-set of JavaScript. C# was a "super-set" of Java. So it's hard comparing them on current basis. Some language worked better in the 80s. Some other worked better in the 90s. And another one worked better in the 00s. A language or toolset created in the 10s has to somehow maintain some support for legacy in order to be popular.

We may disagree about what legacy to support with a new language or toolset as there are all kinds of legacy.

I was not trying to compare output data so much. Making a cross-table of language features is a tough job. Can we do it without such a thing?

>> If you want write about language then write about it. Delphi and the NET Framework are not comparable as programming languages.

I understand you but I have not figured out from the your messages why the Dart is the best programming language for all programmers in world? Just because you do not have experience with other languages?

I did not say it was the best for all programmers even if I implied it. It's the best for me. There's a story about the "worse is better" because worse might be more popular and thus survive longer. Maybe Dart is in some way worse, but is it better as well in that previous sense?

For context:

http://en.wikipedia.org/wiki/Worse_is_better

Let me list 10 points that make Dart a great language for me:

1. fresh and regular syntax in the family of C which turned out to be more popular

2. class

3. functions and closures

4. literals

5. library (in the sense that the language includes flexible library features)

6. var declaration

7. optional types

8. getters/setters

9. string interpolation

10. explicit declarations

I had to look at my code to be reminded of some of them.

When programming for the browser I think those points matter. But then comes all the toolset that Dart offers, like a VM for edit/reload page on the browser, Editor, Dart2JS and so on. Which are peripheral to the language as you duly noted.

I don't think we can do the first point enough justice.

Just looked at my code again. Maybe I forgot to include named parameters as I used those a lot for constructors.

Cheers,

Joao

[john smith]

>> I tried to write something to answer that. But it got long fast with more questions than answers. :-)

Thank you. I understood you.

пятница, 26 июля 2013 г., 18:14:43 UTC+6 пользователь Joao Pedrosa написал:

[JiK]

Dart is a nice language but it has many bad things and many problems so I gave up to use it. The bad things are the underscore to declare private methods and fields, a cumbersome way to write extensions and access external functions inside DLLs or SO, lack of tools for server side programming... The Dart Editor is too bloat, too slow and practically unusable. It is Java based so it will never be fast and good.

[Quildreen Motta]

Dart is still in its infancy, but there's an awesome team of language designers behind it. It's to be expected that the tools aren't mature as in languages that had years to build a whole tooling environment around it, but Dart will get there eventually.

As for the accusations on the editor being too slow and practically unusable just because it's "Java" based (by which I guess you mean JVM), uh... no. Just no. I'm not into IDEs and am an Emacs user, so I don't really know much about Dart's IDE, however I should remind you that LightTable is entirely written on top of a Browser, using ClojureScript (but ultimately running as JavaScript), and is one of the most amazing emerging editors out there.

On 26 July 2013 12:24, JiK <jila...@gmail.com> wrote:

Dart is a nice language but it has many bad things and many problems so I gave up to use it. The bad things are the underscore to declare private methods and fields, a cumbersome way to write extensions and access external functions inside DLLs or SO, lack of tools for server side programming... The Dart Editor is too bloat, too slow and practically unusable. It is Java based so it will never be fast and good.

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

--

--
Quildreen "Sorella" Motta  (http://killdream.github.com/)
— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —

[Joao Pedrosa]

Hi JiK,

>> Dart is a nice language but it has many bad things and many problems so I gave up to use it. The bad things are the underscore to declare private methods and fields,

I'm fond of those. I'm of the opinion that lots of code is already a lot to cope with, so the more we have of it the harder it gets to locate what to review or what to edit next.

Underscore prefix gets out of the way after the first hours of using it. I was reluctant at first, but I had been using a more contrived prefix that I brought with me from JavaScript.

I think you'd prefer keywords to declare stuff public and private and... I prefer to do without those whenever possible.

Variable names with underscore prefix can seamlessly be converted to a getter for example. Perhaps to help with debugging. Perhaps to inject some code into it.

Like so:

class A {

  //var _foo = "stardust";

  get _foo => "bingo";

  changeIt() {

    //_foo = "charm";

  }

  toString() {

    return "A(foo: ${_foo})";

  }

}

main() {

  print(new A()..changeIt());

}

>> a cumbersome way to write extensions and access external functions inside DLLs or SO, lack of tools for server side programming... The Dart Editor is too bloat, too slow and practically unusable. It is Java based so it will never be fast and good.

Reality is that indeed a lot of development happens at the server-side. But a language meant to be on the browser has to be restricted. Code needs to be instrumented to suspend execution of the program and so on.

I've been using the Editor on Windows and it has been OK for me. Funny though that Java has been targeted at the server-side programming and you can see how that can cost on the client-side. That's exactly why Dart needs first to be great at the client-side and then look at the server-side.

Cheers,

Joao

On Fri, Jul 26, 2013 at 12:24 PM, JiK <jila...@gmail.com> wrote:

Dart is a nice language but it has many bad things and many problems so I gave up to use it. The bad things are the underscore to declare private methods and fields, a cumbersome way to write extensions and access external functions inside DLLs or SO, lack of tools for server side programming... The Dart Editor is too bloat, too slow and practically unusable. It is Java based so it will never be fast and good.

--

[Si Robertson]

JiK, you do realise Java is capable of running at a similar speed to compiled native C++ code? The problem with the Dart Editor, if you want to call this a problem, is the use of Eclipse.

I wouldn't call the use of underscores a problem either, it's just a style thing. I wasn't too keen on the use of underscores at first but it didn't take long to get used to it.

The only real problem I have with Dart is the "dart:io" API because it focuses primarily on asynchronous operations which is the wrong thing for an API like that to be focusing on. And the use of Futures is a bit excessive as well. Programmers normally use threads (or "isolates" in Dart's case) if they need to run asynchronous code.

Overall, Dart is nowhere near as bad as you make it sound :-)

I would suggest using a different programming language if you are considering writing a native desktop application though. Dart has been designed for use in internet browsers.

On 26 July 2013 16:24, JiK <jila...@gmail.com> wrote:

Dart is a nice language but it has many bad things and many problems so I gave up to use it. The bad things are the underscore to declare private methods and fields, a cumbersome way to write extensions and access external functions inside DLLs or SO, lack of tools for server side programming... The Dart Editor is too bloat, too slow and practically unusable. It is Java based so it will never be fast and good.

--

[Quildreen Motta]

On 26 July 2013 12:57, Si Robertson <retrom...@gmail.com> wrote:

The only real problem I have with Dart is the "dart:io" API because it focuses primarily on asynchronous operations which is the wrong thing for an API like that to be focusing on. And the use of Futures is a bit excessive as well. Programmers normally use threads (or "isolates" in Dart's case) if they need to run asynchronous code.

I disagree. The use of asynchronous I/O by default is not necessarily a bad thing. And Futures/Streams in Dart (while they surely have a lot of work to do 'till they get better) are pretty neat. Programmers should *never ever never ever* be using threads directly, they're way too low-level — just let the compiler/library figure out how to parallelise your code if you ever need that, and if your compiler/library can't do that, it's not smart enough, and you should look for one that is.

Perhaps what you wanted was something like (sorry it isn't Dart code, I still need to get myself familiar with the language):

val textPromise = io read-file: "/foo/bar.txt".

io print: (@textPromise concatenate-with: "(...)")  -- blocks the first time to dereference the promise.

io print: @textPromise -- doesn't block because it's already resolved.

Clojure and AliceML have these kinds of future, who will block the current execution thread when they're dereferenced before they're resolved. This could be a problem when compiling Dart to JavaScript, though I am not exactly sure of how the concurrency semantics play there so I can't really tell.

At any rate, Futures and Streams allow for fairly declarative asynchronous code for any kind of processing you need, and rather efficiently unless you want to write sequential programs like a Bash script of sorts.

[Si Robertson]

"Programmers should *never ever never ever* be using threads directly, they're way too low-level"

Too low-level for who? Lots of the standard programming languages provide an API for threading code one way or another. Some of those APIs may be more high-level than others but they all essentially hand over the power, and the responsibility, to the programmers. That's generally a good thing.

Asynchronous programming can be a pain in rear to deal with, especially in game code, but it obviously can't be avoided when HTTP pipes (etc) are involved. Ask any professional AAA game programmer if they prefer synchronous or asynchronous programming - chances are they will prefer the former :-)

--

[Quildreen Motta]

AAA game code isn't I/O bound, so that's a moot comparison. Obviously synchronous stuff will be faster for sequential code, but for concurrent code? No.

Just because some methodologies are "mainstream", it doesn't mean they're good. I mean, Java is still one of the most widely used programming languages, and it lacks the most basic language features to do anything in a sane way. Take a look at Go, Erlang, Clojure (with core.async), Haskell, F# (and hell, even C#) and friends to see how they solve the concurrency problem in a neat way without having the programmer deal with low-level stuff.  There have been lots of work on this throughout the history of PLT: first-class continuations and delimited continuations in Scheme, Promises in E/AliceML/etc, Lazy I/O in Haskell, Co-monadic asynchronous stuff in C#, Concurrent Stream Processing in Go/Erlang/Clojure (and previous stuff in literature).

Compare:

(reduce + (map square some-large-data))  ;; synchronous, sequential, single-threaded

(reduce + (pmap square some-large-data)) ;; asynchronous, partially parallel (only map), multi-threaded

(reduce + (pmap square some-large-data)) ;; fully asynchronous, fully parallel, multi-threaded (as long as the ordering of operations isn't specified, so the library is allowed to figure out the best way to reduce the data structure, see core.reducers in Clojure)

Why would anyone even want to deal with low-level threads when the compiler/library can figure out the best way to do that for you. There's really not that much code in a high-level, hosted language (like Dart) that would require one to do manual memory management to force these low-level primitives to be "the default".

[JiK]

On Friday, July 26, 2013 5:57:47 PM UTC+2, Si Robertson wrote:

JiK, you do realise Java is capable of running at a similar speed to compiled native C++ code? The problem with the Dart Editor, if you want to call this a problem, is the use of Eclipse.

In fact, Dart Editor could be written using as base Scintilla or Notepad++, for example, and not Eclipse.

Overall, Dart is nowhere near as bad as you make it sound :-)

Dart is not bad at all but it is still useless. Future will tell. 

I would suggest using a different programming language if you are considering writing a native desktop application though. Dart has been designed for use in internet browsers.

Not completely true, seen there is dart:io. Even Javascript were designed to run on the browser but we already have NodeJs and I think Dart is going just there. So it will be a good solution for web apps using the same language on the browser and on the server. But writing a desktop apps using Dart, or any other interpreted language, is like climbing a mountain with slippers. For desktop apps we use Delphi/FPC and C/C++.

[Si Robertson]

Fair enough. We obviously have our own preferred way of programming and are looking at this from different perspectives, so let's leave things where they are for now. We have also gone way off-topic which wasn't a cool thing for us to do here :-)

[Quildreen Motta]

I would suggest using a different programming language if you are considering writing a native desktop application though. Dart has been designed for use in internet browsers.

Not completely true, seen there is dart:io. Even Javascript were designed to run on the browser but we already have NodeJs and I think Dart is going just there. So it will be a good solution for web apps using the same language on the browser and on the server. But writing a desktop apps using Dart, or any other interpreted language, is like climbing a mountain with slippers. For desktop apps we use Delphi/FPC and C/C++.

That's a rather radical argument without any rational backup. Why do you think C/C++ (and C++ on top of that, which is just a horrible language no no just kill it kill it with fire), or compiled languages in general are the only ones that have a "place" in desktop applications? Lots of GUIs are being written in HTML nowadays, and they're fairly fast! People are also moving from lower level and unsafe languages like C/C++ into safer, higher-level and more modern ones, for example, Firefox will be possibly completely rewritten in Rust as the language matures. Scala and Haskell are also almost as fast as code written in a lower level language like C (in fact, Haskell can beat C for data processing, *and* using immutable data structures!).

There's also plenty of good examples of neat desktop applications written in interpreted languages that are blazing fast, responsive and neat. I could point out to LightTable again, which runs on top of node-webkit and is written in ClojureScript, there's Adobe's Brackets, there's UberWriter (which is Python — in fact, there are a lot of Python GUi stuff out there), also LuaKit, Conkeror, etc, etc, etc.

 

[Si Robertson]

You need to consider what people are actually creating though. The requirements and the structure of a game, for example, is completely different to a normal GUI application.

--

[jim.trainor.kanata]

Matter of opinion! And not shared by everybody. A tiny Unix program
driven by a select call performing async IO on a set of devices
(sockets, storages devices, serial ports, any old driver that implements
select) will outperform anything that attempts to do the same using
blocking calls to OS threads - regardless of the language. Threads are
necessary to keep CPU cores busy. To keep IO devices busy they are
merely a way to organize one's code - and not a terribly scalable one at
that. Java moved away from blocking IO in threads to non-blocking IO
because everyone realized it wouldn't scale. Windows has had completion
ports for this purpose since the beginnings of NT (because it's authors
were form VMS developers who did had done the equivalent there). I
haven't done any Dart server programming yet. I'm expecting good
performance characteristics from what I've read. There programming
model is there to support it.

[Si Robertson]

Well yeah, of course it's just my opinion, but it's based on ~15 years worth of programming experience with various languages. These types of programming discussions are always very opinionated because there are no set-in-stone rules for programming, and one programmer may approach a problem in a completely different way to another programmer, but both will believe their way is the best way :-)

That's why this thread has spiraled so much, and all Joao said was Dart is the best programming language he has ever used. I'm just as guilty as everyone else.

[Quildreen Motta]

On 26 July 2013 15:14, Si Robertson <retrom...@gmail.com> wrote:

These types of programming discussions are always very opinionated because there are no set-in-stone rules for programming, and one programmer may approach a problem in a completely different way to another programmer, but both will believe their way is the best way :-)

There's plenty of rational discussion about these issues and a vast amount of literature in the academia. We haven't found the "One True Way" yet, but we've managed to devise plenty of new awesome ways to deal with old problems! Most programmers are just not familiar with what goes there, unfortunately — I assure you, we also think about the practical applications of our research for everyday programmers, though =/

 

--

[Si Robertson]

"I assure you, we also think about the practical applications of our research for everyday programmers, though"

Programming theory and research is one thing, practical and optimised real world programming is a different beast entirely. The quickest route from A to C isn't always B even though it should be, theoretically.

Out of curiousity, who are you referring to when you say "we" ? If you work for Google (on the Dart team or something) you might want to update your profile because it says you are a hobbyist programmer, as well as a few other things that I won't dare to mention here :-D

FYI, I have enjoyed this conversation so far. I thought I should mention that just in case you are picking up any weird or aggressive vibes from my replies :-)

--

[Quildreen Motta]

On 26 July 2013 16:32, Si Robertson <retrom...@gmail.com> wrote:

"I assure you, we also think about the practical applications of our research for everyday programmers, though"

Programming theory and research is one thing, practical and optimised real world programming is a different beast entirely. The quickest route from A to C isn't always B even though it should be, theoretically.

I wouldn't say that. There's plenty of research going on optimising programs for X purposes, specially in JITs for hosted languages. Speed of execution is not a chaotic thing you can't predict or reason about, there is some disparity about the predicted execution speed of X and the actual execution speed of X due to optimisations performed by the compiler/JIT under certain assumptions that may not be known by the programmer.

 

Out of curiousity, who are you referring to when you say "we" ? If you work for Google (on the Dart team or something) you might want to update your profile because it says you are a hobbyist programmer, as well as a few other things that I won't dare to mention here :-D

No, by "we" I meant "academics" — though I'm not a formally in academia, I spend most of my time researching programming languages and hanging out with other PLT enthusiasts. Sorry if it somehow implied that I worked at Google, I don't (although I'd really love to, since the team consists of several programming language designers I look up to).

 

[Si Robertson]

"I wouldn't say that. There's plenty of research going on optimising programs for X purposes, specially in JITs for hosted languages. Speed of execution is not a chaotic thing you can't predict or reason about, there is some disparity about the predicted execution speed of X and the actual execution speed of X due to optimisations performed by the compiler/JIT under certain assumptions that may not be known by the programmer."

That's true. I was referring to programming APIs and design patterns more than anything else, but you have made a very good point. Understanding how a compiler/JIT behaves is certainly an important factor when it comes to optimisation.

"No, by "we" I meant "academics" — though I'm not a formally in academia, I spend most of my time researching programming languages and hanging out with other PLT enthusiasts. Sorry if it somehow implied that I worked at Google, I don't (although I'd really love to, since the team consists of several programming language designers I look up to)."

No need to apologise, I may have read too much into your previous reply. Good luck for the future, it sounds as though you are really into this stuff so you might actually end up working for Google one day :-)

--

[Josué Ratelle]

Hi,

Last year i made a full mobile web app using dart and i loved it. Since then, I moved to typescript. Here is why:

Dart is great because it's a structured language which javascript kind of lack, but more importantly, dart have a good editor. Also, there was the possibility that dart get included in chrome and we know that chrome is pretty much available on every platform. This should have provide significant performance boost. But dart still fail at it. After two year, it still not available. Dartium doesn't count as it is not mainstream.

What make me change my mind to typescript is that all the existing library for javascript work with typescript. Exemple, i needed a zip library. All i had to do was to write a simple .d.ts file. i did it under ten minutes. For dart, you have to create a wrapper and it require testing.

What is great is that both dart and typescript compile to javascript, but typescript create user friendly javascript. At any time, you can switch back to pure javascript if required without actually being lost in your code.

Also, everyone know that visual studio is far superior to eclipse. Dart team put a lot of effort into the editor and it shows, but it is still a slow horse.

Also, my next project should include bootstrap/ember/nodejs. Going that route, i can't use dart as i can't made a wrapper for every library. I would have to start from strach. I made a lot of stuff back when i did the mobile app, but i cant really find any good business argument that will now make me go dart.

One more thing, when Google annonce that they was going to kill Google Reader, i really questionned myself about continuing using any Google service.

Please! prove i'm wrong!

[Si Robertson]

Dart is fast when it is running in the VM, that is something to bear in mind. If you are creating applications then TypeScript should be fine to use, but 60Hz games generally require more horsepower.

http://www.dartlang.org/performance/

I don't think it will be too much longer before we see the Dart VM baked into Chrome. AFAIK, when Dart reaches version 1.0 Google will begin moving it from Dartium to Chrome :-)

[Fabio Kaminski]

>Also, there was the possibility that dart get included in chrome and we know that chrome is pretty much available on every >platform. This should have provide significant performance boost. But dart still fail at it. After two year, it still not available. 

The js bindings of the dom is in the webkit layer, now that google fork webkit as blink, they should have more control to put bindings to dart there .. now i think it will just be a management problem. if the chromium team will accept to stick dart into blink.. 

but at least, its more easier now then before..

Also dart also have a embeddable vm, so we never know where it may appear next ?! 

(look what happen with node.js because of the v8 been available as a open source project)

For my perspective, as a guy embbeding a language VM, its the best option one might have, as a general computer language, when compared to lua and javascript.. 

Lua/Javascript might fit into the simple scripting world.. but as you need more software composability (as in large projects)

dart appears to be the only fot for it.. (with lua almost there)

--

[Brian Oh]

A couple of comments based on what has been said.

1. Google is very different to what Borland was.

2. Delphi died when AH left, and Delphi was used as a cash-cow by a company run by bean-counters IMHO.

3. IMHO a good language is a language one likes using, is fast enough for its purpose, and is adequately supported by a very competent team. I love using Dart.

4. I don't know why people get turned off by trivialities ("_").

5. Dart still has a couple of hurdles IMHO, but the syntax IMHO is unbeatable, the editor is gr8 the debugger is gr8. Async is a fact of life.
brianoh

[Joao Pedrosa]

Hi Brian,

Thanks for the nice words.

On Sun, Aug 11, 2013 at 2:31 AM, Brian Oh <brians...@gmail.com> wrote:

A couple of comments based on what has been said.

1. Google is very different to what Borland was.

2. Delphi died when AH left, and Delphi was used as a cash-cow by a company run by bean-counters IMHO.

Now that I think of it, maybe several things contributed to it. .NET and the .NET version of Delphi, 64 bits CPUs that demanded 64 bits Delphi, Linux making cross-platform development important and crazy versions of Windows that created incompatibilities. Forgot to add the Internet and bigger networks that made the client-server model obsolete. In that kind of context, no single person could do much.

 

3. IMHO a good language is a language one likes using, is fast enough for its purpose, and is adequately supported by a very competent team. I love using Dart.

4. I don't know why people get turned off by trivialities ("_").

5. Dart still has a couple of hurdles IMHO, but the syntax IMHO is unbeatable, the editor is gr8 the debugger is gr8. Async is a fact of life.
brianoh

I cannot judge Async yet, but I also think it could be the way to go. Like the growth challenges that Delphi faced, scaling to multiple CPUs has been a tough one. I just am not sure it's enough yet. The big thinkers want us writing code in a more abstract format so it could be modeled after more CPUs by delegation to language designers and CPU manufacturers.

At a minimum Async seems to draw a line in the sand of that was before and this is now. What will come after this, I don't know.

All I know is that I think 99% of code that's not IO is not Async anyways.

Cheers,

Joao

 

[john smith]

>> Hi Brian,
>> Thanks for the nice words.

In what is his merit?
In my opinion, he did not say anything conclusive. More than half the comments do not contain any useful information.

[Brian Oh]

Hi Joao, 

Thanks for your reply. While I'm a very practical person, I think it's important to also look at things from an academic perspective. In respect to Borland and any company for that matter, its rarely a situation of looking at the same thing over a period of time. Companies like to say things like eg. "founded in 1883 or 1983", but the forms of Borland were multifarious since formation (albeit a relatively short period of time). All companies have been many different things over any extended period of time. Therefore, it's not relevant to talk about companies in terms of being a separate and distinct entity over a period of time - particularly in IT. Possibly the best things that Borland did was Turbo Pascal (AH) and Delphi (AH). They then thought they could bureaucratize it. That doesn't work with IT, and hopefully it never will, because it puts the bean-counters and the bureaucrats above the creative forces, and it also ignores the brilliance of people in IT to change the status-quo. I've seen that philosophy destroy companies. I could mention examples.

With respect to your other comments, yes, io obtains most of the benefit from async (I think). If that is the situation, then why isn't async confined to IO? Perhaps it should be, but could it be?

With respect to Borland, there was a lot happening - database servers, intense competition, the internet, computer-language evolution. The BDE was (I think) a disaster. In addition, the change from desktop databases to server databases also I think played a major part. There we were, playing around with desktop databases, only to be eclipsed by server databases. It was a huge waste of time - once the inevitable was realised. Borland could have helped alleviate that by making their RDBMS (Interbase) available at realistic prices and make it free up-to a restrictive number of users or database size. I think they were in denial of what was happening (and the latest instantiation is probably the same). Living in denial of reality may make us feel comfortable, however it also leads to our demise.

The thing that I most like about IT is that it brings us down to a common-denominator - what can you do and how well can you do it. While I find that extremely competitive, it brings to the fore the best. It is difficult to argue against that proposition. Unfortunately it will become, as everything eventually becomes, bureaucratised. Until then, lets be creative! I hope that I didn't fail to address anything that you raised.

Regards, Brian.

--

[Brian Oh]

Yeah, maybe.

On Mon, Aug 12, 2013 at 1:28 AM, Michael Haubenwallner <michael.ha...@gmail.com> wrote:

Hi Brian, where does your reference to Borland come from? I cannot find the context you are answering to - did you mix the threads by chance?