I agree here, there's been a few instances over the years where people have
talked about putting the source on Git (I can't believe it's been almost 10
years now), but in the end the only actual contributions have not amounted
to much more than a few changes to the header files to make things easier
to compile on for instance OS X and BSD.

So let's face it, it's just talk without any practical value apart from
making the project perhaps a bit more visible.

In the beginning I had comments on in my bitbucket repo (
https://bitbucket.org/hsarvell/ ) which I quickly turned off due to
statements like "why doesn't it just work, please help me" and the like, no
collaboration whatsoever on the form of "hi I just downloaded and had some
issues that I solved, here's the pull request".

On Thu, Feb 23, 2017 at 10:46 PM, Lindsay John Lawrence <
lawrence.lindsayj...@gmail.com> wrote:

> I am relatively new to picolisp, with limited knowledge of its development
> history... but I'll politely disagree with some suggestions here regarding
> making the core more 'popular' and open to 'collaborative' development.
> Bandwagon collaboration may in all likelihood dull the scapel and result
> in  something far from pico.
> What would be great is to see more of an ecosystem built around the
> picolisp core. Build something awesome with picolisp, document it and share
> it with the world.
> I am.
> /Lindsay
> ~~~~~~~~~~~~~~~~~~~
> Notes: I made as a read through the email thread...penny thoughts, ...a
> bit opinionated and repetitive and therefore subject to change.
> Make what more open? From what I can see, the source going back to at
> least 2002 is freely available for anyone to copy and do with as they like.
> There is no lack of transparency or reluctance to share knowledge.
> Compared to almost every other development tool I have worked with,
> picolisp is a breath of fresh air.  The more I breathe in, study the
> succinct examples on the wiki, rosetta code, 99probs, tankfeeder, etc the
> more I appreciate that. Many of those examples, despite their brevity, are
> far from trivial.
> It is a scapel. A lot a fun to play with. But it is neither a toy lisp, an
> overspecialized lisp, or -- what it feels like to me now -- the 'all things
> to everyone' bloated cruft that is common lisp.
> In the short time I have worked with it, I have yet to write a 'hack' to
> get around some limitation or shortcoming of the picolisp environment. I
> have written a surprising amount of useful code and connected it to other
> tools to do useful things in concert.
> It is lisp. Therefore, initially, "Lots of Irritating, Silly, Parentheses"
>  that with practice, quickly become an appreciated, simple consistent
> syntax. Syntax sugar is overrated. Look at the mess of most other
> programming languages as they try to add 'advanced' features.
> Even as a newbie, I can see how easily the current picolisp core can
> integrate with, or integrate, other tools. How easy it is to leverage
>  functionality like distributed programming, async io, templated
> programming, underlying os pipes, etc that most other runtimes either don't
> provide at all, end up diluting or obfuscating.
> In what other language, even other lisps, is it as easy to say... (= code
> data) ?
> A high performance, general purpose, interpreted runtime engine, in a few
> hundred kilobytes?. I wish I had 'discovered' it a decade ago.

Reply via email to