As a lurker who has just started looking at picolisp, I'm a little hesitant
to contribute to this thread.
I'm coming at this from a slightly different perspective I think than some
other users. This isn't my 1st (nor 2nd, or even 3rd) lisp. What attracted
me to take a look at picolisp?
+ Fully integrated database.
+ Ajax-enabled Web framework
Seriously, thats pretty interesting stuff.
Dynamic binding? Ok, I'll admit I'm not a fan (scheme!). Using transient
symbols as variables? But the new (symbols) namespaces should make dynamic
binding liveable :)
Purely interpreted? So I have some prejudices to overcome on this score
(spoiled by chicken scheme & racket, eg)
I think the one thing which does bother me though, is the lack of a
separate macro-expansion phase. Sure, fexpr's give you what macro's do, at
runtime.
But one of the key things which make me feel comfortable in any lisp is the
knowledge that I can effectively re-arrange the syntax of certain operation
sequences to forms that I prefer.
In other words, the longer one spends in a particular lisp environment, the
more you customise that environment to make it more "yours". And pretty
soon, the differences between it, and other lisp implementations you use
heavily become abstracted away.
Once you get used to this feeling of *freedom*, its really hard to give it
up. And honestly, I think this is one key lisp'ism which picolisp lacks.
Because there is no separate macro-expansion phase, any "macros" which
involve non-trivial re-arrangement of syntax become more burdensome to do -
because you're painfully aware that you are going to be paying the cost for
it at runtime - every time.
Which means that one tends to settle for the (for want of a better word)
idioms/methods that picolisp provides 'as is'.
Picolisp is something which you have built over the years to solve your
problems, in the way you want them solved. Which is great. But also, very
personal and idiosyncratic idioms tend to creep in (eg: the strong
preference for building lists dynamically, and not having any
quasiquote-like templates)
I hope this doesn't read as a criticism of any particular style (apologies,
if thats what it seems like). Its just that, any ONE style will not fit all.
Is this a change which would significantly increase complexity? Honestly, I
don't think so. Its just re-writing code, picolisp -> picolisp (once, at
definitiion time, instead of every time the code is invoked)
Picolisp does deserve more positive press for some of the really
interesting things it *DOES* have. For that, you need more folks to use
picolisp on real stuff. Simple examples with real code.
Allowing them to bend picolisp to *their* personal tastes would help to
attract them.
--
Regards,
Imran Rafique
On 23 January 2012 00:58, Alexander Burger <a...@software-lab.de> wrote:
> Hi all,
>
> many thanks for all your replies!
>
> First of all, I must apologize. I did not want to blame the community.
>
> But, on the other hand, Henrik is right. Though I don't agree with his
> original argument about the lack of libraries, PicoLisp is indeed dead
> at least in one important way. My personal survival depends on PicoLisp
> -- not so much on how it is liked by programmers, but on how it is
> accepted by potential customers (for project work). Spreading the news
> that PicoLisp can't be used because there are no libraries is quite
> devastating, but also without that, acceptance for project work didn't
> improve during the ten years since PicoLisp went public.
>
> Please don't worry about the future of the language itself. I will
> continue to develop and use it in my own projects as before. But I must
> invest more time into my own economic survival.
>
> Again, many many thanks!
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
