Optical Illusions in Flutter Examples

[tatumizer-v0.2]

Flutter Examples provide a rare opportunity for psychological experimentation and theorising with respect to visual pattern recognition.

As a first example, let's contemplate the following fragment:

 Widget build(BuildContext context) {
    return new Material(
      child: new Center(
        child: new Column(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          children: <Widget>[
            new Text('Hello from Flutter!'),
            new RaisedButton(
              child: new Text('Get Location'),
              onPressed: _getLocation
            ),
            new Text('Latitude: $_latitude, Longitude: $_longitude'),
          ]
        )
      )
    );
  }

Can you see how "child"/"children" stand out here? Why do they? My theory is that our Mind is very good at capturing repeating patterns. Due to this "pattern recognition effect", our Mind perceives token "child" as the main character of the scene, whereas everything else at best serves as a background or decoration (*)  

Since "child" tokens carry very little information here (indentation is more than enough to express parent-child relationship), they distract us from appreciating the semantics of the expression.

As an experiment, let's try to remove "child" and "children". Suppose we allow one of the named parameters of constructor to declare itself a "list of children" (the name of parameter itself can be anything), in which case we don't need to use its name in object literal at all, and are not supposed to explicitly write it as list. Instead, we can write each child independently, each time ADDING it to a list (so, expression ": x" in the literal is treated as "add x to the list of children")

Let's rewrite our example using new notation:

 Widget build(BuildContext context) {
    return new Material(
      : new Center(
        : new Column(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          : new Text('Hello from Flutter!'),
          : new RaisedButton(

              onPressed: _getLocation,
              : new Text('Get Location')
            ),
          : new Text('Latitude: $_latitude, Longitude: $_longitude'),
        )
      )
    );
  }

After modification, term "new" becomes a repeating pattern, adding no value to presentation, but distracting from the real content. Let's remove it, too:

 Widget build(BuildContext context) {
    return Material(
      : Center(
        : Column(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          : Text('Hello from Flutter!'),
          : RaisedButton(

              onPressed: _getLocation,
              : Text('Get Location')
            ),
          : Text('Latitude: $_latitude, Longitude: $_longitude'),
        )
      )
    );
  }

Isn't it GOOD? Crisp, clear code, joy to write and look at.

It's my conjecture that the change alone may turn dart from "meh" language to "two thumbs up!" language, especially for UI programming.

Opinions are welcome!

(*) The alternative theory is that we have just too many nested blocks

[Bob Nystrom]

Yes, I agree, Dart's syntax has some limitations that are particularly painful in Flutter's style code. In particular:

• The new keyword is (and has always been) pointless.
  
• Not allowing positional arguments after named arguments forces "child" and "children".
  
• Not supporting varargs/rest params, forces an explicit collection literal.
  

If you just fix those, it would give you:

  Widget build(BuildContext context) {

    return Material(

      Center(

        Column(

          mainAxisAlignment: MainAxisAlignment.spaceEvenly,

          Text('Hello from Flutter!'),

          RaisedButton(

            onPressed: _getLocation,

            Text('Get Location'),

          ),

          Text('Latitude: $_latitude, Longitude: $_longitude'),

        )

      )

    );

  }

That's a good bit better, but not super great in my book. The ";" and "," are still kind of annoying, as are all of the ")". But it gets increasingly hard to do much about those without making some more radical syntax changes.

Cheers!

– bob

--
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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Lex Berezhny]

Bob, all the things you said: Yes please!

[tatumizer-v0.2]

Yeah, your variant is better. 

There's a bit of a problem with vararg: it cannot be made a required parameter (needs to accommodate size 0, where we pass nothing). So it's optional, Which means that if we have vararg, it should be defined as optional positional parameter, and the *only one* at that (otherwise the setup is ambiguous).

Not a very restrictive rule though, looks benign.

So.... what stops you from doing it?

[Frank Pepermans]

Why not some markup language?

[tatumizer-v0.2]

"Some markup language" - you mean XML? HTML?

Doesn't fit in dart. Syntax like from the other planet.

[Frank Pepermans]

Works in angular 2, worked for flex, and it is optional

On 22 Sep 2016 20:57, "tatumizer-v0.2" <tatu...@gmail.com> wrote:

"Some markup language" - you mean XML? HTML?

Doesn't fit in dart. Syntax like from the other planet.

[Eduardo Teixeira Dias]

I really do not like to shove together controller and view....

It gets ugly fast...

I think that an optimized AngularDart2 for Mobile (Cordova or other mean) much better from a maintenance point of view...

--

Saudações,

Eduardo Teixeira Dias

------------------------------------------

Tendencies Consultoria Ltda.

Tel: 11 3828-1281

Cel: 11 9 9246-4192

[Lex Berezhny]

On Thu, Sep 22, 2016 at 3:06 PM, Eduardo Teixeira Dias <edu...@tendencies.com.br> wrote:

I really do not like to shove together controller and view....

It gets ugly fast...

Can you explain what you mean?

[tatumizer-v0.2]

Frank, could you take this example from Bob, rewrite it in XML and explain why you prefer it over this one.

  Widget build(BuildContext context) {

    return Material(

      Center(

        Column(

          mainAxisAlignment: MainAxisAlignment.spaceEvenly,

          Text('Hello from Flutter!'),

          RaisedButton(

            onPressed: _getLocation,

[Eduardo Teixeira Dias]

I mean that if angulardart2 + cordova becames good enough, It will be easier to develop and keep complex applications in angulardart2 + cordova than using flutter.

--

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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Istvan Soos]

On Thu, Sep 22, 2016 at 9:18 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:
> Frank, could you take this example from Bob, rewrite it in XML and explain
> why you prefer it over this one.

This example is really simple to grasp all of the differences. Maybe a
complex component with repeated (ngFor) and conditional (ngIf)
subtemplates?

Compiling an XML markup to dart code may provide best of both words:
easy to describe hierarchies and compile-time type safety.

Cheers,
Istvan

[Eduardo Teixeira Dias]

It is not easy to match the power of HTML5 + CSS3 for the view.

--
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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Frank Pepermans]

Sure, as mentioned, it is but a simple example, some markup would be preferable with complex views.

It's easy on the eyes and even easier to add new stuff or delete obsolete tags when needed,

you can move it to another file i.e. *.fxml to keep things tidy

Quick one =>

Widget build(BuildContext context) => '<Material>
    <Center>
        <Column mainAxisAlignment="{MainAxisAlignment.spaceEvenly}">
            <Widget>
                <Text>Hello from Flutter!</Text>
                <RaisedButton (pressed)="_getLocation">
                    <Text>Get Location</Text>
                </RaisedButton>
                <Text>Latitude: $_latitude, Longitude: $_longitude</Text>
            </Widget>
        </Column>
    </Center>
</Material>';

[Eduardo Teixeira Dias]

Maybe even a valid angular2 template using a subset of HTML

[Frank Pepermans]

Actually,

Widget build(BuildContext context) => '<Material layout="{Layout.Center}">
        <Column mainAxisAlignment="{MainAxisAlignment.spaceEvenly}">
            <Widget>
                Hello from Flutter!
                <RaisedButton (pressed)="_getLocation">Get Location</RaisedButton>
                Latitude: $_latitude, Longitude: $_longitude
            </Widget>
        </Column>
</Material>';

Or whatever variant

[tatumizer-v0.2]

Sorry, I can't really agree your variant is better. It's a foreign language, with its own rules and conventions - strange ones, like "(pressed)=" and more.

.

There's an option to take less ambitious react-style JSX, - indeed, compared with CURRENT dart style, just anything would be an improvement, but I find Bob's variant good enough. Do you agree on "good enough"?

[Frank Pepermans]

Yeah I would actually :)

But will dart ever change to accommodate this style? Big maybe, some react like markup, whatever the looks, can be easier to accomplish today.

Just look at angular 2, works fine with Dart the way it is today

[Bob Nystrom]

On Thu, Sep 22, 2016 at 11:43 AM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

So.... what stops you from doing it?

Just the usual things around language design. Making sure the feature doesn't interact poorly with other things, getting everyone on board with the idea, figuring out all of the nasty corner cases of the semantics, etc.

We've got a lot of other stuff going on right now, but hopefully we'll be able to look at small-scale sugar stuff like this at some point.

Cheers!

– bob

[krupal shah]

Actually, I work on Android so I can give you a better feedback. I am comparing these with my XMLs : The point is XMLs looks even bad than this. And When I refactor class names or move something from my project (For example, just copying a XML layout from one project to another); It never complains about missing classes. It just crashes at runtime.

Also, I hate writing markup languages for layouts. XMLs forces me to repeat everything. For example, If I want to draw four slices of a rectangle with linear layouts, then I have to end up taking 4 different LinearLayouts. I wish I could write something like:

for (int i=0 to 4){

  draw me a <LinearLayout>

}

When layouts become complex, XMLs become spaghetti's. The bad Android view groups like RelativeLayouts add a sauce on it. XML layouts are always hard to read and change. I can write the same layout using pure Java code. But unfortunately, Java version will make it 10 times larger and complex than XML. I wish I would have some sort of Groovy based DSL like Gradle for layouts.

At least, the Flutter does the right thing by not involving a markup language for layouts. I wish some good expressiveness for readability and hope if language itself adopt more readable and expressive syntax from 2.0.

[krupal shah]

After two years of writing XMLs for Android, I would say NO to these ugly Markup Languages; especially XML for layouts. If you don't agree, try it for a year and write some complex layouts or ask any Android Dev. you will realise the pain better.

[Frank Pepermans]

Nobody likes markups, they exist mostly because the underlying language is too limited to cleanly solve the problem.

I agree that large xml views are like spaghetti, then again coming from flex, I never really had that problem with mxml, also you can always move an xml chain to somewhere else and import it.

I think for now what would work best is to combine both, either build from code as in the current flutter examples, or from something xml based.

Flutter is new and needs to convince people to use it, the current syntax will turn many heads.

Whereas an xml like alternative for a v1.0, with the option to entirely skip it and go for a pure Dart code solution, wouldn't be so bad at all.

I'd personally love a super clean solution entirely made in pure Dart, but it may take quite some time still.

On 22 Sep 2016 22:24, "krupal shah" <krupal...@gmail.com> wrote:

I don't really understand what is meant by child and children in Flutter. But, looking at the syntax,

1. it looks wired and like a callback hell. 

2. Your example looks very clean but these semicolons need to be removed. (from the language itself) 

3. Varargs are necessary instead of collection literals.

Actually, I work on Android so I can give you a better feedback. I am comparing these with my XMLs : The point is XMLs looks even bad than this. And When I refactor class names or move something from my project (For example, just copying a XML layout from one project to another); It never complains about missing classes. It just crashes at runtime.

Also, I hate writing markup languages for layouts. XMLs forces me to repeat everything.

For example, I want to draw four slices of a rectangle with linear layouts, then I have to end up taking 4 different LinearLayouts. I wish I could write something like:

for (int i=0 to 4){

  draw me a <LinearLayout>

}

When layouts become complex, XMLs become spaghetti's. The bad Android view groups like RelativeLayouts add a sauce on it. XML layouts are always hard to read and change. I can write the same layout using pure Java code. But unfortunately, Java version will make it 10 times larger and complex than XML. I wish I would have some sort of groovy based DSL like (Gradle)[https://docs.gradle.org/current/userguide/tutorial_using_tasks.html] build system for layouts.

[Eduardo Teixeira Dias]

Did you wrote some angulardart2 components?

2016-09-22 17:38 GMT-03:00 krupal shah <krupal...@gmail.com>:

After 2 years of writing XMLs for Android, I would say NO to these ugly Markup Languages; especially XML for layouts. If you don't agree, try it for a year and write some complex layouts or ask any Android Dev. you will realise the pain better.

[krupal shah]

Haven't written yet. Looked at AngularDart a few days ago. But, they look more like DSL. Also, they aren't pure XML/HTML. Are they? 

[Eduardo Teixeira Dias]

They are HTML + CSS.

Very easy to compose...

*ngFor, *ngIf, Router, Forms, Pipes

2016-09-22 17:49 GMT-03:00 krupal shah <krupal...@gmail.com>:

Haven't written yet. Looked at AngularDart a few days ago. But, they look more like DLS. They aren't pure XMLs. Are they? 

[Lex Berezhny]

The kinds of things that Flutter can do are not possible with HTML + CSS.

That's kind of the whole premise to Flutter.

Flutter is genuinely something new, not just an incremental improvement over existing tech.

[Don Olmstead]

What can Flutter do that isn't possible in the browser? I haven't taken a deep dive into Flutter since you can't develop on Windows so I'm genuinely curious since it was built by taking apart a browser.

--

[Lex Berezhny]

On Thu, Sep 22, 2016 at 7:08 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

What can Flutter do that isn't possible in the browser? I haven't taken a deep dive into Flutter since you can't develop on Windows so I'm genuinely curious since it was built by taking apart a browser.

Flutter is closer to the GPU which lends itself to much more sophisticated and performant animations and visuals.

I think at this point so much of Chrome has been removed that there is little resemblance except for some non-web related technologies (mojo, skia, etc). Flutter doesn't use the DOM or CSS or any of the other staple web technologies.

Basically there is the Flutter engine, implemented in C++, which exposes relatively high level APIs to Dart. In Dart you have the material widgets and the functional-reactive style framework.

You could theoretically implement this in the browser with JavaScript and WebGL but then much of what Flutter does in C++ you'd be doing in JavaScript, there is an obvious performance limitation here...

 - lex

[tatumizer-v0.2]

 >... figuring out all of the nasty corner cases of the semantics, etc.

Upon reflection: syntax of vararg is not as obvious either.

If you make it "optional positional parameter", then what to do about default value, e.g.

foo([String x="hello" ...]);  // absurd

So variadic optional parameter cannot have default value. But optional parameters always have "default default" value (null)

Which means vararg should be branded "required". But it really isn't required.

Paradox. Not a BIG paradox, but still...

[Bob Nystrom]

If it were up to me, I think the basic idea would be that a function can define (in this order):

• Some number of required positional parameters.
  
• Some number of optional positional parameters.
  
• A possible varargs parameter.
  

Varargs are neither required nor optional parameters. They are a third kind of thing.

(There are named parameters too, but they don't interfere with this, so we can ignore them.)

When binding arguments to parameters, you fill in the required ones first, then the optional ones, then any remaining ones go into the varargs list. So (using made up syntax):

function(a, b, [c, d], e...) {

  print("required $a, $b, optional $c, $d, varargs $e");

}

function(1, 2, 3, 4, 5, 6) // prints "required 1, 2, optional 3, 4, varargs [5, 6]".

function(1, 2, 3, 4, 5)    // prints "required 1, 2, optional 3, 4, varargs [5]".

function(1, 2, 3, 4)       // prints "required 1, 2, optional 3, 4, varargs []".

function(1, 2, 3)          // prints "required 1, 2, optional 3, null, varargs []".

function(1, 2)             // prints "required 1, 2, optional null, null, varargs []".

function(1)                // compile error

This should extend naturally to named varargs too, which are a fourth kind of parameter and would be passed to you as a Map.

Cheers!

– bob

[Filipe Morgado]

ActionScript3 varargs has a hidden performance cost, allocating a brand new array on every method call, even if it's empty.

It's common practice to avoid varargs methods when performance matter.

For example, I never use array.push(...), but array.insertAt(array.length, item) instead. It doesn't create GC pressure and the call itself is a lot faster.

It's sad to offer a feature that turns out to be explicitly avoided.

In Dart, I suppose named parameters are internally implemented as regular positional parameters.

If they were implemented as a map, I believe it would hurt quite a lot since they're pretty much everywhere.

In your example, named parameters could still be positional, right after optional ones.

Maybe varargs could be passed to the method as a const List, re-using a VM-wide instance if it's empty.

[Filipe Morgado]

Oh, then comes the million dollar question ...

Would it map well to JS?

[Don Olmstead]

Right it doesn't have a DOM or CSS I get that. I don't see why you couldn't compile HTML and CSS out to something flutter can consume.

--

[Filipe Morgado]

It seems easier to implement a Flutter backend the web can consume.

On Friday, 23 September 2016 03:07:20 UTC+1, Don Olmstead wrote:

Right it doesn't have a DOM or CSS I get that. I don't see why you couldn't compile HTML and CSS out to something flutter can consume.

On Thursday, September 22, 2016, Lex Berezhny wrote:

[tatumizer-v0.2]

@Bob:

>Varargs are neither required nor optional parameters. They are a third kind of thing.

Yes, I was thinking about the same thing, but you beat me.

>This should extend naturally to named varargs too, which are a fourth kind of parameter and would be passed to you as a Map.

Not sure this extends naturally. There's no syntax even to declare such thing. e.g

foo({x, y, andThenWHAT?}) {...}

More importantly, I can't see a massive use case which would justify it. For vararg of the LIst kind, we have massive use case in UI (flutter, DOM etc)

For Map vararg one - I am not aware of such use case. And if you *occasionally* need to pass optional map, you can do via explicit named parameter.

foo({int x, int y, Map<String,String> myOptionalMap}) {...}

Sure, you have to use extra { } in invocation:

foo({x: 5, myOptionalMap: { "foo": "bar"}})

 - but since it's rare, no one would complain.

 

[Lex Berezhny]

On Thu, Sep 22, 2016 at 10:07 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Right it doesn't have a DOM or CSS I get that. I don't see why you couldn't compile HTML and CSS out to something flutter can consume.

Flutter uses functional-reactive programming model... meaning that when you create a widget you cannot mutate it, the attributes are all final, to change anything you have to re-create the widget and rebuild that part of the widget hierarchy. Conversely, the standard way to interact with DOM is via the imperative programming model, you can mutate the DOM, change the attributes of elements, you can move elements around, etc. I don't think you can just automate the conversion between these two programming models...

If you wanted to bring HTML and CSS to the Flutter engine you would basically re-implement the modern web browser: parsing HTML, building a DOM model, implementing event handling and then all of the logic of how to convert a DOM tree and associated CSS into draw calls... At this point why not just use Cordova or similar? Seems like a much saner approach.

If you wanted to bring your Flutter app to the browser then as I said before you would probably have to re-implement the Flutter engine C++ code in JavaScript and WebGL - or - maybe someday Flutter engine will run in WebAssembly.

 - lex

[Lex Berezhny]

Just so we don't get carried away in theories and abstractions...

This is the Flutter engine (C++) API you'd have to implement, "dart:ui":

https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html

The rest of the Flutter framework: material widgets, the functional-reactive framework, etc, all build on top of the "dart:ui" engine API.

Flutter engine (C++): https://github.com/flutter/engine

Flutter framework (Dart): https://github.com/flutter/flutter

 - lex

[Frank Pepermans]

It sounds a lot like react native to me, not that I've used either that or flutter before?

https://github.com/facebook/react-native/blob/master/Examples/Movies/MovieScreen.js

--

[Filipe Morgado]

So, one could just swap the implementation of "dart:ui" (and other services the app uses) when targeting the web, ideally without changing a thing in our code.

Aren't configurable imports supposed to allow this kind of stuff?

[Lex Berezhny]

On Fri, Sep 23, 2016 at 7:25 AM, Filipe Morgado <pix...@gmail.com> wrote:

So, one could just swap the implementation of "dart:ui" (and other services the app uses) when targeting the web, ideally without changing a thing in our code.

Aren't configurable imports supposed to allow this kind of stuff?

You say that like "dart:ui" is trivial :-)

Configurable imports is going to be the easiest part of all this.

[Benjamin Strauß]

Funny, Gilad had a blog post about this back in 2014.

https://gbracha.blogspot.com/2014/11/a-dsl-with-view.html

[Filipe Morgado]

It wasn't my intention to make the implementation look trivial. Just highlight the ease of deployment to multiple targets, including the web, if there was "dart:ui" implementation for the web.

Everything seems to align pretty well with browser APIs and CSS, except for MojoServices, which could be a pain to implement (and a performance bottleneck).

[Benjamin Strauß]

I thought about that too. Maybe one could write an implementation for "dart:ui" ontop of stagexl (https://github.com/bp74/StageXL).

[krupal shah]

CSS is a DSL. and that's why it's good.

The problems with markup languages can be solved by Domain Specific Languages. That capability should be in the language itself. Languages like Groovy do a great job using powerful meta-programming capabilities and closures. The characteristics of essence over ceremony is a need for writing UI elements. Scala and Kotlin also have good capabilities. I don't know anything about Dart's meta-programming capabilities yet.

[tatumizer-v0.2]

@Bob: there's a potential use case for hypothetical "map vararg": it can be used as parameter of map constructor itself.

Currently, we have to write quotes in map literals. Majority of map literals has String keys, so the quotes are redundant and annoying.

If Map provides constructor with "map vararg" parameter, then instead of

var map = {

   "foo": 1,

   "bar": 2  

}

we can write

var map = Map(

   foo: 1,  // no quotes

   bar: 2

);

Not sure this is a sufficient justification, but I find it rather funny.

[Lex Berezhny]

Python does it pretty much exactly like that:

>>> map = {

...    "foo": 1,

...    "bar": 2  

... }

>>> map

{'foo': 1, 'bar': 2}

>>> map = dict(

...   foo=3,

...   bar=4

... )

>>> map

{'foo': 3, 'bar': 4}

[tatumizer-v0.2]

> Python does it pretty much exactly like that:

Agree with "pretty much", but not with "exactly"

In python, there are colons in one place, and = in another.

In the hypothetical dart case, there are colons only.

Big difference!

[kc]

Maybe something like Rust macros. Or a more advanced form of ES6 template strings.

// Flt - flutter dsl

var layout = flt! {
   // something in here less verbose and easy on the eye

}

K.