← Back to team overview

ooc-dev team mailing list archive

SDK, batteries included and Unix principles


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 ?

Follow ups