Discussions

@cbae:  Considering that code is read more times than it is written, I'd say that anything that makes code less readable should be reduced.

Take for example some simple XAML code from https://gist.github.com/forki/2161484 (randomly chosen from a quick search):

<Window xmlns="http: //schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http: //schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid Name="MainGrid">
        <StackPanel Name="StackPanel1">
            <Button Name="Button1">First Button</Button>
            <Button Name="Button2">Second Button</Button>
        </StackPanel>
    </Grid>
</Window>

And what it could be (a language I made up on the spot):

Window (Title: "MainWindow", Height: 350, Width: 525)
{
    Grid MainGrid
    [
        StackPanel StackPanel1
        [
            Button Button1 { "First Button" }
            Button Button2 { "Second Button" }
        ]
    ]
}

Which is easier for you to read?

2 hours ago, jinx101 wrote

One thing I've learned is that the language a professional developer uses doesn't necessarily dictate their competence level. 

That is true with mainstream languages.  But if a programmer uses newer or lesser-known languages, like F#, that to me says a lot.

28 minutes ago, fanbaby wrote

I am also waiting for Anders Hejlsberg to work on a JavaScript replacement that would be MSIL based

Just so long as this is completely open and unconstrained from being cross-platform.  Otherwise, adoption rate will be extremely low.  At best, it already has to battle the giant that Javascript has become.

Our best bet would be if Microsoft, Google, Mozilla, and Apple came together to form a standards coalition to replace Javascript.  If they all supported the end result in each of their browsers, the foundation would be there for actually moving to world to the new language and eventually reducing support for Javascript.

I just hope that such a replacement is compatible with both HTML and its replacement, whenever that comes to fruition.

As much as I'd like to see a replacement for XAML, I'd give a first priority to replacing HTML/JS.  It saddens me that HTML is being embraced even more today.  And the languages that have been built to replace JavaScript are really more about extending it, not about fixing its inherent flaws.

3 hours ago, Dr Herbie wrote

XML is better if humans ever have to read it.  Right tool for the right job.

I love the quote attributed to Chris Maden:  "XML is like violence: if it doesn't solve your problem, you aren't using enough of it."

I disagree about XML being the right tool for the job.  It is a decent hierarchical data description format.  It's not great at describing various hierarchical and non-hierarchical visualization aspects and runtime interactions.

Microsoft somewhat recognized this fact while designing XAML.  That's why we have markup extension language.  Caliburn similarly introduced an action syntax to improve the deficiencies of XML format for this purpose.

5 hours ago, Sven Groot wrote

XAML was designed for easy tooling. XML makes perfect sense for that. The bloat only matters if you want to write it by hand (and even then a good editor will take care of most of it).

Of course, the only tooling most people use has been created by Microsoft.  Maybe it was a cool idea, but never really blossomed.  Part of the reason it probably never blossomed is that XAML isn't a simple conversion to IL.  The compile time and runtime descriptions of XAML are quite complex.

And I do write most of my XAML by hand.  I understand those who don't, but like myself there are plenty of people who only use the designer view, not the editing capabilities.

4 hours ago, Bas wrote

I'd gouge my eyes out if XAML was based on JSON.

I'm not advocating that.  QML has a syntax similar to JSON (but only in that they both use C-like block syntax).  It has specific advantages over JSON like not using quotes in attribute names.  (Note that I've never actually developed in QML... I just like it in theory because it reduces bloat.)

1 hour ago, vesuvius wrote

This was as important on tablets where size is important so the successor or XAML in WPF, is XAML in WinRT.

Sorry, but no.  There are so many lockdowns and restrictions on the WinRT framework that you cannot call it a successor.  Our LOB applications have hardware and extensibility capabilities that WinRT does not provide, which forces us to use WPF.

Besides, it doesn't fix one of my chief complaints:  XAML is based on XML.  It is unnecessary bloat from an era that thought XML was the solution for everything.

@figuerres:  Of course I don't want to go back to Winforms.

But XAML is the new Winforms.  It is a good platform, but there are specific deficiencies that have come to light.  This is normal for a language.  But there are some languages that by design can be updated for years to come, like C#, and there are languages that have key design deficiencies that can't easily be fixed without breaking backwards compatibility, like XAML.

I think it's getting time that the successor to XAML come along, or at least it's time that Microsoft begins the design of that language.

2 days ago, bondsbw wrote

Your second argument is sound though.

16 hours ago, BitFlipper wrote

Your analogy misses the whole point that there is no technical limitation at all that you can't develop for WP8 on Windows 7.

Please read.

Honestly, I wish it would.

Hear me out.  I program almost exclusively in WPF, but one of the big drawbacks is XAML.  It was part of Microsoft's, frankly, silly attempt to use XML everywhere.  Now, that XML gets in the way everywhere.

A varienty of improvements can be had:

• I would much rather have a succinct syntax like QML.  
• The UI code needs to be compile-time checked as much as possible.  Data bindings would seriously improve.  And there are too many instances where I have to run through my entire application debugging it just to find out I mistyped a resource reference.
• For that matter, get rid of BAML.  Compile directly to IL and skip most of the runtime interpretation aspect.
• And for now this is last but certainly not least: ICommand.  We need something better.