It is my impression, that the consulting market has changed
very rapidly. Some years ago it was possible to find very interesting
tasks based on databases etc... and Alaska XBASE was a great
platform.

Now, at least in Sweden, almost only .NET is requested
along with VB,  C++   and some HTML+XML  to solve almost all
programming tasks.  Even delphi seems to be a very , very small
alternative, and ALASKA XBASE is totally un-known !

I would look forward to the comments form the XBASE community,
how to get new jobs and how to approach this new situation,
still beeing able to use the XBASE knowledge.

How would that help the situation if there will be a .NET version
of  XBASE  ?  Would that increase the acceptance of XBASE
in the present market situation  ?




Best regards
Bengt Ovelius

Bite the bullet and learn .NET and Java.

Thats what I have done and I am about to leave my job and become solely 
a .NET developer.


Mike

Bengt Ovelius wrote:
> It is my impression, that the consulting market has changed
> very rapidly. Some years ago it was possible to find very interesting
> tasks based on databases etc... and Alaska XBASE was a great
> platform.
> 
> Now, at least in Sweden, almost only .NET is requested
> along with VB,  C++   and some HTML+XML  to solve almost all
> programming tasks.  Even delphi seems to be a very , very small
> alternative, and ALASKA XBASE is totally un-known !
> 
> I would look forward to the comments form the XBASE community,
> how to get new jobs and how to approach this new situation,
> still beeing able to use the XBASE knowledge.
> 
> How would that help the situation if there will be a .NET version
> of  XBASE  ?  Would that increase the acceptance of XBASE
> in the present market situation  ?
> 
> 
> 
> 
> Best regards
> Bengt Ovelius
> 
> 
> 
> 
> 
>

Net languages have a high level of integration, in xbase i can't integrate 
VB,Delphi source
The common language runtime (CLR) is responsible for run-time services such 
as language integration, security enforcement, and memory, process, and 
thread management. In addition, the CLR has a role at development time when 
features such as life-cycle management, strong type naming, cross-language 
exception handling, and dynamic binding reduce the amount of code that a 
developer must write to turn business logic into a reusable component.


YES A xbase.net can increase the acceptance of XBASE if it will be ready in 
one or two years

"Bengt Ovelius" <____no_spam_____pico@telia.com> ha scritto nel messaggio 
news:Or0jgwQYFHA.3104@S15147418...
> It is my impression, that the consulting market has changed
> very rapidly. Some years ago it was possible to find very interesting
> tasks based on databases etc... and Alaska XBASE was a great
> platform.
>
> Now, at least in Sweden, almost only .NET is requested
> along with VB,  C++   and some HTML+XML  to solve almost all
> programming tasks.  Even delphi seems to be a very , very small
> alternative, and ALASKA XBASE is totally un-known !
>
> I would look forward to the comments form the XBASE community,
> how to get new jobs and how to approach this new situation,
> still beeing able to use the XBASE knowledge.
>
> How would that help the situation if there will be a .NET version
> of  XBASE  ?  Would that increase the acceptance of XBASE
> in the present market situation  ?
>
>
>
>
> Best regards
> Bengt Ovelius
>
>
>
>
>
>

"Bengt Ovelius" <____no_spam_____pico@telia.com> wrote in 
news:Or0jgwQYFHA.3104@S15147418:

> Now, at least in Sweden, almost only .NET is requested
> along with VB,  C++   and some HTML+XML  to solve almost all
> programming tasks.  Even delphi seems to be a very , very small
> alternative, and ALASKA XBASE is totally un-known !

I'm not sure things have changed that much. 5 years ago VB was the most 
requested, now it's .NET. Even in the hayday of Clipper  I don't recall 
many jobs advertising for Clipper experience.

> I would look forward to the comments form the XBASE community,
> how to get new jobs and how to approach this new situation,
> still beeing able to use the XBASE knowledge.

Where Clipper (and Xbase++) has been most successful is in the small 
company developing vertical apps. 

> How would that help the situation if there will be a .NET version
> of  XBASE  ?  Would that increase the acceptance of XBASE
> in the present market situation  ?

As I see it, there are 2 possibilities: 

1. If Xbase++ .NET is very good (better in some way than C#), then 
Xbase++ will gain marketshare.

2. If Xbase++ .NET provides no advantages over C# (beyond the language 
syntax), then Xbase++ will loose marketshare. Existing companies using 
Xbase++ will use the .NET version to start migrating away from Xbase++ 
towards tools with the Microsoft logo.

Therefore, the challange for Alaska Software is to make a better (easier, 
faster, smarter, etc...) .NET compiler than Microsoft.

Best regards,
Boris Borzic

http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Boris,

> I'm not sure things have changed that much. 5 years ago VB was the most 
> requested, now it's .NET. Even in the hayday of Clipper  I don't recall 
> many jobs advertising for Clipper experience.
> 
>> I would look forward to the comments form the XBASE community,
>> how to get new jobs and how to approach this new situation,
>> still beeing able to use the XBASE knowledge.
> 
> Where Clipper (and Xbase++) has been most successful is in the small 
> company developing vertical apps. 

Traditionally, Clipper contractors have made their services available to
companies running Clipper projects.  Therefore, you advertise your Clipper
developing credentials and look out for requests for Clipper developers.

Xbase++ contractors, in many respects, do exactly the same.  I suspect that
this is where Bengt lies - either a contractor looking for Xbase++ work, or
a permanent employee keeping an eye on the market for future potential.

I think the onus has changed considerably in this era of multi-choice
lnaguage/compilers.  Rather than offer a service providing Xbase++
experience and expertise, you would be better off offering solutions.

For example, someone wants a system to monitor stock levels, you offer a
solution which meets these requirements (or rather, show you can develop
one specific to their requirements).  The customer usually doesn't care
about which language it is written in, only that they can have it, and that
you (or someone else) will provide maintenance in the future.  This opens
your market to companies that have requirements, but absolutely no
development resource at all and so have to outsource.

Once you have some experience in a particular market, you might develop
some tools and/or libraries and frameworks to make building a particular
type of system quickly (e.g. most stock systems are fairly generic, and
most tailored solutions differ only in the detail), and perhaps even build
an off-the-shelf system that you can resell time and again - possibly
making a big thing of the fact that you can (and will) tailor this package
to suit individual demands.

For my own part, I am trying to develop a business model where I am using
Xbase++ to do my work, but I'm not dependant upon people seeking me out
because I use Xbase++.  Such a model has two major benefits:

  1.  A much broader market
  2.  I could (if I wanted to) change to another language/compiler
      without affecting the business in any way.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

God helps them that help themselves.
		-- Benjamin Franklin, "Poor Richard's Almanac"

Spot on Phil, I agree.

I think we are all a bit guilty of being too focussed on the language 
and maintain a blinkered view.


Mike

Phil Ide wrote:
> Boris,
> 
> 
>>I'm not sure things have changed that much. 5 years ago VB was the most 
>>requested, now it's .NET. Even in the hayday of Clipper  I don't recall 
>>many jobs advertising for Clipper experience.
>>
>>
>>>I would look forward to the comments form the XBASE community,
>>>how to get new jobs and how to approach this new situation,
>>>still beeing able to use the XBASE knowledge.
>>
>>Where Clipper (and Xbase++) has been most successful is in the small 
>>company developing vertical apps. 
> 
> 
> Traditionally, Clipper contractors have made their services available to
> companies running Clipper projects.  Therefore, you advertise your Clipper
> developing credentials and look out for requests for Clipper developers.
> 
> Xbase++ contractors, in many respects, do exactly the same.  I suspect that
> this is where Bengt lies - either a contractor looking for Xbase++ work, or
> a permanent employee keeping an eye on the market for future potential.
> 
> I think the onus has changed considerably in this era of multi-choice
> lnaguage/compilers.  Rather than offer a service providing Xbase++
> experience and expertise, you would be better off offering solutions.
> 
> For example, someone wants a system to monitor stock levels, you offer a
> solution which meets these requirements (or rather, show you can develop
> one specific to their requirements).  The customer usually doesn't care
> about which language it is written in, only that they can have it, and that
> you (or someone else) will provide maintenance in the future.  This opens
> your market to companies that have requirements, but absolutely no
> development resource at all and so have to outsource.
> 
> Once you have some experience in a particular market, you might develop
> some tools and/or libraries and frameworks to make building a particular
> type of system quickly (e.g. most stock systems are fairly generic, and
> most tailored solutions differ only in the detail), and perhaps even build
> an off-the-shelf system that you can resell time and again - possibly
> making a big thing of the fact that you can (and will) tailor this package
> to suit individual demands.
> 
> For my own part, I am trying to develop a business model where I am using
> Xbase++ to do my work, but I'm not dependant upon people seeking me out
> because I use Xbase++.  Such a model has two major benefits:
> 
>   1.  A much broader market
>   2.  I could (if I wanted to) change to another language/compiler
>       without affecting the business in any way.
> 
> Regards,

Mike,

> Spot on Phil, I agree.
> 
> I think we are all a bit guilty of being too focussed on the language 
> and maintain a blinkered view.

I like to think I am more 'job' oriented - I use the tool that is best for
the job with 'best' defined as one or more of:

  a) Easiest to complete the task
  b) Most apt for the task (e.g. C/C++ for developing an OS)
  c) Easiest to maintain on a high-maintenance project
  d) Meets the job requirements (e.g. speed or size may be a factor)

There are other criteria of course, but Xbase++ usually is top choice
because of it's high language level, low requirement to worry about memory
allocation/de-allocation etc., and the various libraries available which
make development very much easier.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Those who can, do.  Those who cannot, teach.  Those who cannot teach,HACK!

The firms that look for programmers, often ask for a .... programmer (where 
.. could be clipper or can be .net, c# etc.) and state the language in 
advance.
It has sometimes be difficult to convince people that I have general insight 
in programming languages and I'm good in analytic thinking.
They have in general no patience to let people learn these languages, you 
better learn in it your own time.

In any case, the firm where I'm working at the moment, I'm content with.

B. Vink

"Phil Ide" <phil@idep.org.uk> wrote in message 
news:45nn3cah21lu$.dlg@idep.org.uk...
> Mike,
>
>> Spot on Phil, I agree.
>>
>> I think we are all a bit guilty of being too focussed on the language
>> and maintain a blinkered view.
>
> I like to think I am more 'job' oriented - I use the tool that is best for
> the job with 'best' defined as one or more of:
>
>  a) Easiest to complete the task
>  b) Most apt for the task (e.g. C/C++ for developing an OS)
>  c) Easiest to maintain on a high-maintenance project
>  d) Meets the job requirements (e.g. speed or size may be a factor)
>
> There are other criteria of course, but Xbase++ usually is top choice
> because of it's high language level, low requirement to worry about memory
> allocation/de-allocation etc., and the various libraries available which
> make development very much easier.
>
> Regards,
> -- 
> Phil Ide
>
> ***************************************
> * Xbase++ FAQ, Libraries and Sources: *
> * goto: http://www.idep.org.uk/xbase  *
> ***************************************
>
> Those who can, do.  Those who cannot, teach.  Those who cannot teach,HACK!

Phil,

A whole group of Xbase++ users is, I think, forgotten in these musings.
This seems to be mostly about programmers who work independantly, building
programs on a contract basis.
Most Xbase++ users that I know have their own, mostly small, company that
develops a single product or a range of products which they market
themselves. In that situation the marketing power of the development
platform is much less important, you can choose the platform that suits you
best.
For us this is Xbase++. We do use other platforms for special products but
we find that Xbase++ programming productivity far exceeds that of other
platforms and that the product stability is also much better. Especially
the VB.NET development was a grave disappointment. Programming productivity
and stability are disastrous compared to Xbase++ and NO, we did not try to
do that on the cheap, we hired some really good developers for that.
So, Bengt and Mike, you better be really careful when moving to .NET, it is
certainly not all 'rosescent and moonshine' as we say in Holland. Good luck
anyway.

Regards,
Jan Groenestein

I know .NET has its problems but it does have more upsides than 
downsides. 


I do not have a choice. My new job is a .NET position so that it what I 
am going to be doing. I will however keep an eye on these newsgroups.


Regards

Mike



Jan Groenestein wrote:
> Phil,
> 
> A whole group of Xbase++ users is, I think, forgotten in these musings.
> This seems to be mostly about programmers who work independantly, building
> programs on a contract basis.
> Most Xbase++ users that I know have their own, mostly small, company that
> develops a single product or a range of products which they market
> themselves. In that situation the marketing power of the development
> platform is much less important, you can choose the platform that suits you
> best.
> For us this is Xbase++. We do use other platforms for special products but
> we find that Xbase++ programming productivity far exceeds that of other
> platforms and that the product stability is also much better. Especially
> the VB.NET development was a grave disappointment. Programming productivity
> and stability are disastrous compared to Xbase++ and NO, we did not try to
> do that on the cheap, we hired some really good developers for that.
> So, Bengt and Mike, you better be really careful when moving to .NET, it is
> certainly not all 'rosescent and moonshine' as we say in Holland. Good luck
> anyway.
> 
> Regards,
> Jan Groenestein

We too have moved a lot on .NET and are almost about to finish a huge ERP
development in the same.
Will try to post sometime about it out here. Specially because, I have put
my time on the same, not as a developer.
I have been in the team (part-time) only to contribute my domain-knowledge
of the subject and experience in computing and programming.

Am contiuning and taking care of our core product in Xbase++ itself. (So am
staying back here 

Anand

NB: Steffen, would appreciate a word from you/your team on a tentative date
for the next release. My pre-occupation is restricting me to participate
actively in the beta. 1.8's memory management, NTX concurency
(fast/optimised record lonking), Stable ADS support and ActiveX, is what am
looking forward.
Also, the 'flicker-free' handlings of GUI. Have read, 1.9 takes care of alll
these.

"Mike Grace" <mikeg@computastat-group.co.uk> wrote in message
news:42A41C44.6030302@computastat-group.co.uk...
> I know .NET has its problems but it does have more upsides than
> downsides. 
>
>
> I do not have a choice. My new job is a .NET position so that it what I
> am going to be doing. I will however keep an eye on these newsgroups.
>
>
> Regards
>
> Mike
>
>
>
> Jan Groenestein wrote:
> > Phil,
<snip>