ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

Hah, no answers on such an interesting topic =)

Well, 'batteries included' is interesting but hardly sustainable in the long
term. Besides, imho the ooc module system (especially with use files) makes
it easy enough to split into a kazillion libs. I only wish
nirvana/meatshops/reincarnate would become more mainstream. Maybe when fred
gets back.

There are still some areas where I'm not sure whether to include something
or not in the SDK. UTF-8 is a good example: we can either go with utf8proc
(quite lightweight, but with limited support), or go full-blown using ICU,
but that's a huge dependency. My opinion is that it should be opt-out, so
that embedded setups are still pretty easy to achieve.

What are you thinking, llamaistas[1]?

Amos (nddrylliog)

[1] (c) 2010 fredreich 'python, me?' bier.

On Sun, May 2, 2010 at 4:07 PM, Fabien Bourgeois <fabien.8@xxxxxxx> wrote:

> 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 ?
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>