3 ms·

This is my main point of criticism about Dart (and Flutter SDK design). While Flutter is incredibly pleasant to work with compared to native Android or iOS SDKs

by Taig 8y ago

This is my main point of criticism about Dart (and Flutter SDK design). While Flutter is incredibly pleasant to work with compared to native Android or iOS SDKs, it still feels so terribly ill-conceived in so many areas coming from a functional background. For the Dart part the Future-problems you already mentioned and the need for async/await language level keywords is disappointing. Also if/else not being an expression as well as syntactic complexity (e.g. defining constructors with factory/static/const keyword combinations). Why come up with a new language in 2011 that repeats the null mistake? Flutter gives you a beautiful and comprehensive set of widgets and makes a great first impression. But when digging a bit deeper, things tend to get ugly. Massive side effects hidden deep inside OOP structures (e.g. routing), stuff like mixins, validation tied into view layer etc. I couldn't help but find so many mistakes being repeated. After spending a couple months with Flutter, I decided to ditch mobile development all together. I wish they followed the direction react is steadily going: promoting simple, pure widgets and passing values around, avoiding side effects.

munificent 8y ago
> the need for async/await language level keywords is disappointing This is unfortunate [1], I agree. The challenge is that if you don't do that, it's very hard to compile the resulting code to efficient JavaScript. Dart was initially only a web language and is now both a web and a mobile language. You can think of function calls as having two different calling conventions: return the value normally, or return it by invoking a continuation with the result. Asynchronous functions require the latter. You could compile all function calls to that style, but it's much slower and generates larger JS. You could try to infer which functions should be called using an async style and which shouldn't. That works in simple cases, but breaks down in complex cases involving generics and higher-order functions. I don't know of any literature that investigates how feasible this is in practice, so making your language rely on this optimization for tolerable performance is a very large gamble. This may change over time now that JS has generators and may be adding async/await syntax, but Dart was designed before either of those existed. > Also if/else not being an expression Yeah, everything being an expression is nice. I wish Dart had been designed that way. The original designers of the language believed they needed to be very conservative in order to be successful and I think they overshot that mark. > syntactic complexity (e.g. defining constructors with factory/static/const keyword combinations) Some of this is annoying, yes. It does have some practical value, though: * The restriction around initializing final fields in the constructor initialization list, which is what forces you to use factory constructors in some cases, ensures a very nice property: it means in Dart you can never observe a final field before it has been initialized. This is not true in C#, Java, or Kotlin. Now that we are working on non-nullable types for Dart [2], this will let us have sound non-nullable types, unlike those other languages. * Personally, I find const to be more of a hassle than it's worth, but const constructors do let you define real compile-time constant objects of user-defined classes, which isn't something some other languages can express. That, in turn, lets you rely on very fast identity tests for checking equality between two objects. Flutter relies on this heavily when diffing the widget tree to determine which parts have changed efficiently. > Why come up with a new language in 2011 that repeats the null mistake? Tell me about it [3]. (Note the date on that blog post.) We're working to fix it now. [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... [2]: https://github.com/dart-lang/language/issues/110 https://github.com/dart-lang/language/issues/110 [3]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-null-safety-in-dart/ http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

by Taig 8y ago

munificent 8y ago

> the need for async/await language level keywords is disappointing This is unfortunate [1], I agree. The challenge is that if you don't do that, it's very hard to compile the resulting code to efficient JavaScript. Dart was initially only a web language and is now both a web and a mobile language. You can think of function calls as having two different calling conventions: return the value normally, or return it by invoking a continuation with the result. Asynchronous functions require the latter. You could compile all function calls to that style, but it's much slower and generates larger JS. You could try to infer which functions should be called using an async style and which shouldn't. That works in simple cases, but breaks down in complex cases involving generics and higher-order functions. I don't know of any literature that investigates how feasible this is in practice, so making your language rely on this optimization for tolerable performance is a very large gamble. This may change over time now that JS has generators and may be adding async/await syntax, but Dart was designed before either of those existed. > Also if/else not being an expression Yeah, everything being an expression is nice. I wish Dart had been designed that way. The original designers of the language believed they needed to be very conservative in order to be successful and I think they overshot that mark. > syntactic complexity (e.g. defining constructors with factory/static/const keyword combinations) Some of this is annoying, yes. It does have some practical value, though: * The restriction around initializing final fields in the constructor initialization list, which is what forces you to use factory constructors in some cases, ensures a very nice property: it means in Dart you can never observe a final field before it has been initialized. This is not true in C#, Java, or Kotlin. Now that we are working on non-nullable types for Dart [2], this will let us have sound non-nullable types, unlike those other languages. * Personally, I find const to be more of a hassle than it's worth, but const constructors do let you define real compile-time constant objects of user-defined classes, which isn't something some other languages can express. That, in turn, lets you rely on very fast identity tests for checking equality between two objects. Flutter relies on this heavily when diffing the widget tree to determine which parts have changed efficiently. > Why come up with a new language in 2011 that repeats the null mistake? Tell me about it [3]. (Note the date on that blog post.) We're working to fix it now. [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... [2]: https://github.com/dart-lang/language/issues/110 https://github.com/dart-lang/language/issues/110 [3]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-null-safety-in-dart/ http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...