[Harbour] Harbour roadmap ?

[Szakáts Viktor]

Hi,

The goal is to have a C5.2e compatible compiler.

I have these in mind when thinking about future directions:
- Full "unicode" support (including unicode .prg files)
- Proper and native multilanguage support (i18n)
- Multithreading
- Strong typing
- Native classes (without PP) (?)
- Creating a documented function call equivalent for
   all command-only feature (like PACK).
- I'd feel it important to focus on Harbour being used
   as a scripting language. Do we miss anything in this area?
   (compiler switches definitely don't match well with this one)

I'm personally against any l'art pour l'art feature frenzy
especially when it comes to the base language (statements,
operators). Clipper is a very strong language, we have
plenty of ways (too much even IMO) to express logic with it,
and I'm not sure we would need to concentrate on adding
new and new ones. (Otherwise at the end, everyone will
have his/her own pet feature right there in the core, right,
but source code will look like Frankenstein, portability
suffers, new users will not get it, code will depend on
several compile time switches (;so code by itself will not
be enough to see what the code actually does), and we will
end up with 10 #ifdefs in every source code, just like in C,
to make something compile under 2-3 flavours of Clipper
compatible compilers. All these are bad for a language.)

Sometimes, less is more.

So rather, if we want to modernize the language and make it
stronger, we might want to make the language slimmer, simpler,
with less variations, preferring the higher quality features
of it, and fading the really obsolete (legacy) part of it.
All this, in an optional and compatible fashion, of course.

In parallel we can build libs to implement different APIs
for common tasks needed for today's business apps, like:
- Proper, portable page orientated printing.
- SQL support.
- proper XML support.
- Polished communication interface for POP3, SMTP, FTP, HTTP
   GET/PUT, generic TCPIP, etc, mail message parsing and creation.
- SSH/SSL support where it applies.
- Wrappers for nowadays essential extensions, like CURL, LDAP,
   SQLITE, etc.
- Some random features like PDF, image formats, ZIP, BZIP, TAR
- GUI (controversial, maybe even impossible, but definitely
   important)

All these can be developed as fully external libs (some
of the already exist), but eventually it might be good
to include them in core. If we want to do this, we need
to have a clear definition on the feature set and a high
level of standard when defining the API.

Brgds,
Viktor


On 2007.10.05., at 15:41, Teo Fonrouge wrote:

> Hello,
>
> Is there such thing as a roadmap doc ?, or there is a implicit "be  
> a Clipper
> 5.xx compatible compiler" unique milestone.
>
> If there is not a roadmap, maybe we need to define one.
>
> As anyway, the statement "be a Clipper 5.xx compatible compiler" is  
> a main
> goal, then the folowing simple questions arise:
>
>  * What is the status of this compatibility, and how this is  
> measured ?
>
>  * If the current compatibility level of Harbour compiler is a  
> almost complete
> one, then what is next ?
>
> I have seen lately too much references to the word "compatibility"  
> in the
> posts, but compatibility against what seems a little ambiguous to  
> me now.
> Harbour has, and hopefully will have, great features that most  
> certainly
> enrich the language beyond the Clipper limits. So, why to keep some  
> of this
> features 'outside' of the standard Harbour language and worst,  
> calling this
> as a xHB's compatibility lib.
>
> I believe, that this features along with the planned ones (i.e. I  
> have seen
> lately references to 'strong typing' ) are the natural and logic  
> consequence
> of the a intrinsic evolution of the language.
>
> If Harbour is currently a *high* level Clipper compatible language  
> why not to
> leave this as version 1 ?
>
>
> best regards
>
> Teo
> _______________________________________________
> Harbour mailing list
> Harbour at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour