ooc-dev team mailing list archive

[Fabien Bourgeois <fabien.8@xxxxxxx>]

Last but not least : I think we can (re)debate about your vision on 
ooc's future, about how the language sould be placed compared with other 
technologies, especially about its SDK.

There can be a few positions, as I see them :

1. *The SDK can stay minimal*. This point of view favours targeting 
embedded hardwares, lightweight and well-tested core. In this case, we 
could imagine semi-official bindings and pure ooc libraries, which can 
be easily installed with reincarnate, as easy_install for Python. This 
is what makes sense for me about Unix philosophy : make small tools than 
can talk each other, just pay what you eat and employ existing tools.

2. To give ooc the direction of a *middle-size standard library*, as we 
can have in.. Vala or maybe Javascript. That's true many things are 
commonly useful : regexp, date, math, xml...

3. To want a *batteries included* language, as Python or Google Go. The 
idea is to let newcomers do almost everything with ooc.

A variant could be to write a pure ooc "batteries included" library 
apart from the SDK, to let those who wants embedded or lightweight 
things use only the SDK and to provide others a good base ecosystem.

My point of view :

Although an huge batteries included standard library is an appealing 
idea, I think there are pretty good languages which have already it and 
I believe this is too much work for our small community.

Concerning what I called "middle-size" stdlib, the debate is open but I 
think Vala will be a great challenger if we chose this way.

As you have surely guessed, I think the first option might be the best :

1. This is *less work*, and I think you have already so many things to do

2. I believe that creating and maintaining good bindings can be timeless 
than create many existings libs in pure ooc from scratch. ooc seems to 
integrate very well with C and there are many quality C libraries. Using 
them can reassure some users and supply to ooc a *big collection* of use 
cases. And then, ooc killer apps can be made more easily!

3. KISS and Unix philosophies are, to my mind, considered concepts. 
There is a movement to come back to them, which can be seen, relatively 
speaking, with Archlinux, Uzbl or even the suckless project. 
Strategically, set up ooc as a *KISS language* can bring us experimented 
users with which we share common principles.

Your opinions ?