68.1 F
Los Angeles
Friday, April 26, 2024

Trump Lawyer Resigns One Day Before Trial To Begin

Joseph Tacopina has filed with the courts that he will not represent Donald J. Trump. The E. Jean Carroll civil case is schedule to begin Tuesday January 16,...

Judge Lewis A. Kaplan Issues Order RE Postponement

On May 9, 2023, a jury found Donald J. Trump liable for sexual assault and defamation. The jury awarded Ms. Carroll $5 million in damages. Seven months ago,...

ASUS Announces 2023 Vivobook Classic Series

On April 7, 2023, ASUS introduced five new models in the 2023 Vivobook Classic series of laptops. The top laptops in the series use the 13th Gen Intel® Core™...

XAML thoughts

Someone messaged me the other day about an ink-based forms designer for XAML. Yeah, it would be an interesting idea (although in the implementation it might be tricky to get things to line up nicely.)

To me the “forms” designers are going to be critical for XAML. I don’t see myself coding in it. I might drop down to XAML to check something, but I don’t see myself handcrafting XAML like so many people are doing in XAML demos. It doesn’t impress me that you can hardcode a bunch of gradient surfaces in ten lines of XAML code. In fact, I’d expect it to be possible to design the surfaces in some UI.

XAML’s value is in large part due to the new graphics capabilities being made available in Longhorn. All this can be done in plain old code, of course–no XML needed–just updated APIs.

On the practical side, XAML is also an incremental improvement in how the UI is represented in C# code, which carries the same design issues as Delphi in terms of maintaining round-trip editing changes in the development environment.

However, what I hope Microsoft stumbles into is ways of not reducing the number of lines of code for a human as so often XAML demos emphasize, but rather to make it easier for a computer to generate and maintain code. This is where the ultimate value of declarative “languages”, such as XAML lies. We need to make our computers better coders.

It’s far easier to write a computer program to process XML and analyze declarative statements than run through C++ or C# or whatever. Imagine, for instance, a module in the development environment that analyzes UI changes you make to ensure that buttons are in order, spacing is reasonable, sizes are right, and corporate layout standards are being followed—all as you edit the code. It’s a challenge to conceive of writing such a module if you had to parse C# directly and figure out what’s going on in the UI–where the animated icons are, for instance. “Reasoning” about a declarative file is still not trivial, but it’s much easier.

This is where I expect to see languages going in the future. I expect to see new programming languages that make it easier for the computer to process and analyze and as a result make me more productive–and make non-programmers more productive too. XAML might just be one step along the way.

Loren
Lorenhttp://www.lorenheiny.com
Loren Heiny (1961 - 2010) was a software developer and author of several computer language textbooks. He graduated from Arizona State University in computer science. His first love was robotics.

Latest news

Related news