Productivity

[wriedmann]

Hello,

as most of you know, I have several applications written in X# Core with WPF in production. And the last two years I have tried to write all the small utilities I need all the time in X# Core, mostly using the Console class, but a few also in WinForms and WPF.

Now, last week I needed another small utility and decided to write it using the X# runtime and the VO dialect, mostly to use the VO style arrays. I was really surprised how fast I was compared to the development in X# Core!
Yesterday I then have worked on the X# VOGUI application that I have in production for a few months now (using the Vulcan runtime), and again, I was surprized how easy and fast it was to do my development work.

One could now say that it is my missing experience to make development faster with the X# runtime. But IMHO it is another issue: when developing the .NET runtime, fast development of business applications was not on the plan. Therefore the .NET functions (or better: methods) throw exceptions every time when something is not as expected.
A simple example: the VO SubString() function returns simply a shorter string, when the passed string is shorter than expected. The String:SubString() method in the .NET Frameworks throws an exception. To make it behave like the VO function, several lines of code are needed:

Code: Select all

static method SubStr( self cString as string, nStart as int, nLen as int ) as string
// 0-based!!!
local nStringLen as int
local cReturn as string

nStringLen := cString:Length
if nStart < 0
  if ( nStart * -1 ) >= nStringLen
    nStart := 0
  else
    nStart := nStringLen + nStart
  endif
endif
if nLen >= ( nStart + nStringLen )
  cReturn := cString:Substring( nStart )
else
  cReturn := cString:Substring( nStart, nLen )
endif

return cReturn

One could now say the the .NET Framework behavior is more correct, but in business applications rather the VO behavior is needed.

My conclusion is now that I will continue to write future applications in WPF MVVM, but using the X# runtime, but only if the customer is willing to pay the more time for the dynamic look of WPF applications (currently I would save that nearly the double of the time is needed).
For the applications where the development is price-sensitive, I will wait for the promised WinForms based VOGUI compatible classes because I'm much faster than with WPF, and future proof is not more an issue since WinForms will be available also in .NET Core, like WPF.

These my observations are personal ones, and many of you will not agree. But I work in a particular market: most of my work (and the work of my company) are not large scale applications, but applications written for one customer.

Wolfgang

[Chris]

Hi Wolfgang,

I mostly agree with you, in my opinion it's unfortunately the c/c++ guys that apparently had their say while designing .Net, so except for the good things, we are also stuck with things like zero based arrays and collections, even string char indexes, very strict string operations etc. Nothing wrong with using the X# runtime, this is why it exists.

Chris

[wriedmann]

Hi Chris,
I have no problems with 0-based arrays and collections, but I had preferred 1-based collections.
But this is something I can adapt me.
What I don't like is the entire exception system - it makes me write a LOT of code. Sometimes the error handling is more code than the executed code itself.
Wolfgang