PicoLisp and its (lack of) libraries
Hi all, from time to time, some people (hmm, to be exact, only Henrik so far ;-) write that the main obstacle for the acceptance of PicoLisp is its lack of libraries (e.g. [1]). I must say that I strongly disagree. I never felt this to be a problem, despite using it for decades of various kinds of programming. As Henrik also wrote, nobody wants to reinvent the wheel. Very true. The intention of PicoLisp is to _avoid_ writing extensive libraries, and rather use existing libs implemented in other languages. For that, accessing external programs and libs is made especially easy and transparent in PicoLisp. For many common tasks, like data format conversions or information retrieval, it is convenient to call shell commands or tools written in Perl or other languages with simple pipes: (in (list 'some-program arg) (while (line) ...)) Interfacing to native C functions is also nice (especially in the 64-bit version, see e.g. lib/openGl.l). Do we really want somebody to write tons of code which already exists (well debugged) in other languages? In addition, many features do already exist in the PicoLisp base system, where other languages need special libraries for. Let's look at Python, being a typical competitor to PicoLisp. I'll just pick some examples at random from rosettacode.org. In all of these cases (and I don't know if I found the typical examples here) -- where Python explicitly imports libraries to solve the task -- the PicoLisp solutions don't need to import any library, and are even shorter usually: http://rosettacode.org/wiki/Find_the_missing_permutation from itertools import permutations http://rosettacode.org/wiki/Knapsack_problem/Bounded from itertools import groupby from collections import namedtuple from pprint import pprint as pp http://rosettacode.org/wiki/Last_Fridays_of_year import calendar http://rosettacode.org/wiki/Last_letter-first_letter from collections import defaultdict http://rosettacode.org/wiki/Longest_string_challenge import fileinput http://rosettacode.org/wiki/Odd_word_problem from sys import stdin, stdout http://rosettacode.org/wiki/One_of_n_lines_in_a_file from random import randrange http://rosettacode.org/wiki/Ordered_words import urllib.request http://rosettacode.org/wiki/Pangram_checker import string, sys http://rosettacode.org/wiki/Parallel_calculations from concurrent import futures from math import floor, sqrt http://rosettacode.org/wiki/Parse_an_IP_Address import string from pyparsing import http://rosettacode.org/wiki/Partial_function_application from functools import partial http://rosettacode.org/wiki/Pick_random_element http://rosettacode.org/wiki/Random_number_generator_(device) import random http://rosettacode.org/wiki/Price_fraction import bisect http://rosettacode.org/wiki/Prime_decomposition import sys http://rosettacode.org/wiki/Priority_queue import queue http://rosettacode.org/wiki/Probabilistic_choice import random, bisect http://rosettacode.org/wiki/Rate_counter import subprocess import time http://rosettacode.org/wiki/Ray-casting_algorithm from collections import namedtuple from pprint import pprint as pp import sys http://rosettacode.org/wiki/Read_a_specific_line_from_a_file from itertools import islice http://rosettacode.org/wiki/Rock-paper-scissors from random import choice, randrange from bisect import bisect from collections import defaultdict http://rosettacode.org/wiki/Secure_temporary_file import tempfile http://rosettacode.org/wiki/Self-referential_sequence from itertools import groupby, permutations http://rosettacode.org/wiki/Send_email import smtplib http://rosettacode.org/wiki/Sequence_of_non-squares from math import sqrt http://rosettacode.org/wiki/Seven-sided_dice_from_five-sided_dice from random import randint http://rosettacode.org/wiki/Show_the_epoch http://rosettacode.org/wiki/Sleep http://rosettacode.org/wiki/System_time import time http://rosettacode.org/wiki/Sockets import socket http://rosettacode.org/wiki/Soundex from itertools import groupby http://rosettacode.org/wiki/Stable_marriage_problem import copy http://rosettacode.org/wiki/Stack from collections import deque http://rosettacode.org/wiki/Stem-and-leaf_plot from collections import namedtuple from pprint import pprint as pp from math import floor http://rosettacode.org/wiki/Subtractive_generator import collections http://rosettacode.org/wiki/Table_creation/Postal_addresses import sqlite3 http://rosettacode.org/wiki/Take_notes_on_the_command_line import sys, datetime, shutil http://rosettacode.org/wiki/Terminal_control/Clear_the_screen
Re: PicoLisp and its (lack of) libraries
On January 13, 2012 at 12:45 PM Alexander Burger a...@software-lab.de wrote: As Henrik also wrote, nobody wants to reinvent the wheel. Very true. The intention of PicoLisp is to _avoid_ writing extensive libraries, and rather use existing libs implemented in other languages. For that, accessing external programs and libs is made especially easy and transparent in PicoLisp. Then a good chunk of examples using foreign libraries would help a lot. Seeing is believing. A little picolisp editor using gnome libs and gtk, an SDL game, a web client using CURL libraries and so on. best regards, Jakob --=_Part_49_1132727072.1326458988197 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;html xmlns=http://www.w3.org/1999/xhtml; head meta content=text/html; charset=UTF-8 http-equiv=Content-Type/ title/title /head body p style=margin: 0px;/p p style=margin: 0px;/p div style=margin: 5px 0px 5px 0px; On January 13, 2012 at 12:45 PM Alexander Burger lt;a...@software-lab.degt; wrote:br/ br/ gt;br/ gt; As Henrik also wrote, nobody wants to reinvent the wheel. Very true. Thebr/ gt; intention of PicoLisp is to _avoid_ writing extensive libraries, andbr/ gt; rather use existing libs implemented in other languages. For that,br/ gt; accessing external programs and libs is made especially easy andbr/ gt; transparent in PicoLisp. /div p style=margin: 0px;#160;/p p style=margin: 0px;#160;Then a good chunk of examples using foreign libraries would help a lot./p p style=margin: 0px;Seeing is believing. A little picolisp editor using gnome libs and gtk,/p p style=margin: 0px;an SDL game, a web client using CURL libraries and so on./p p style=margin: 0px;#160;/p p style=margin: 0px;best regards,/p p style=margin: 0px;Jakob/p p style=margin: 0px;#160;/p /body /html --=_Part_49_1132727072.1326458988197-- -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp and its (lack of) libraries
Hi Jakob, =C2=A0Then a good chunk of examples using foreign libraries would help a lo= t. Seeing is believing. A little picolisp editor using gnome libs and gtk, an SDL game, a web client using CURL libraries and so on. No. Not at all. I think this is a typical misunderstanding of the PicoLisp spirit. What would a little picolisp editor help to increase the popularity of PicoLisp? You know about the editor wars? Why reinvent the wheel? You can perfectly call 'vi', 'emacs' or any other editor you like from within or without PicoLisp. An SDL game is not a library, it is an application. That's fine. But also not something like a killer app for PicoLisp, IMHO. SDL itself is written in C. So you can USE it, right? Not reinvent the wheel! BTW, speaking of C-libraries like SDL: If you claim that PicoLisp lacks libraries, then you must say the same about C. Virtually any C-library can be called in PicoLisp. Using 'curl' is what I do in almost every application. Again, why reinvent the wheel and write a _library_? I find myself quite often calling (in (list 'curl -s -l ... or (call 'curl -T ...) or whatever you like. In rosettacode.org you find also examples where 'curl' is called from PicoLisp: http://rosettacode.org/wiki/HTTPS#PicoLisp http://rosettacode.org/wiki/HTTPS/Authenticated#PicoLisp http://rosettacode.org/wiki/HTTPS/Client-authenticated#PicoLisp Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
subscribe
Hello Bastien b...@altern.org :-) You are now subscribed -- Bastien -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A collection of demonstrations of how to use PicoLisp
Hi Jakob, I will not quote, because I did not make myself very clear I think. I am not proposing a PicoLisp editor for the sake of an editor, or the writing of extensive PicoLisp only libraries. Yes, I understand. But my original mail was just about that. I argue, (or tried - unsuccessfully) for the value of having a few examples of how to call C libraries. Hmm, I think there are already quite some examples, for one in the PicoLisp distribution: lib/math.l lib/openGl.l misc/fibo.l misc/crc.l or in rosettacode: http://rosettacode.org/wiki/Active_Directory/Connect#PicoLisp http://rosettacode.org/wiki/Call_a_foreign-language_function#PicoLisp http://rosettacode.org/wiki/Call_a_function_in_a_shared_library#PicoLisp http://rosettacode.org/wiki/Joystick_position#PicoLisp http://rosettacode.org/wiki/MD5#PicoLisp http://rosettacode.org/wiki/Regular_expressions#PicoLisp http://rosettacode.org/wiki/Truncate_a_file#PicoLisp http://rosettacode.org/wiki/Window_creation/X11#PicoLisp When I said curl, I did not mean curl, the application, but curl, the library. Yes, I understood that too. Calling the external 'curl' program is easier, though, and the overhead should not matter here. - Like a very tiny gameloop calling the SDL library. OK - Something using the curl library. (Not forking the curl binary.) Yes, but see my comment above. - Something which uses a Fast Fourier Transform library [http://www.fftw.org/] . Or any idea, I just quickly tried to come up with something. Good idea! There is also a rosetta task about that, iirc. So, yes, examples are good and important. But this was not the reason why I wrote the original posting. It was about _which_ libraries are lacking, inhibiting PicoLisp to be useful. In addition to writing it in the IRC channel, Henrik complained about that in several places, e.g. http://comments.gmane.org/gmane.lisp.picolisp.general/1558 Take for instance what I see as the biggest problem with PicoLisp; the lack of existing libraries for doing common suff. http://www.mail-archive.com/picolisp@software-lab.de/msg01983.html Having a Java version might help PL a lot on the popularity front, it should completely bypass the catch 22 problem of low interest due to to few libraries and few libraries due to low interest. http://programmers.stackexchange.com/questions/60796/what-are-the-reasons-why-clojure-is-hyped-and-picolisp-widely-ignored it makes sense that Clojure would win out over Pico-Lisp solely for its compatibility with existing programming languages and existing libraries. and this is what I don't agree about, and would like to discuss. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp and its (lack of) libraries
Hi Damir, On raising popularity... I've taken the task of making default contact management app from Picolisp source look modern by taking CSS up a notch - and failed miserably. Reasons? A) css html is mingled with code and B) I'm used to templates representing HTML, not functions (html within code). I've Hmm, I see. In fact, I don't see that as a real problem. There are hooks for CSS in the HTML functions, and there is quite some flexibility in either passing styles to the functions, or wrapping styles around code blocks. Besides that, it is good to remember that all those HTML functions are just examples, you may easily modify them or write similar instances. They are nothing more than printing functions, you can directly (prin ..) or (ht:Prin ...) at any time. got lost in small functions and failed to see he big picture. I agree. Sometimes, too much flexibility can cause a nightmare ;-) I've gone to far off topic here... To make it popular? Top Rails's scaffolding in short video with distributed DB and all that stuff and I'm sure people would be interested. Actually, making PicoLisp popular wasn't my primary intention when writing the original post. It was about the situation with (the lack of) libraries, which, as a consequence, reduce popularity (at least according to Henrik). As I see it, the problem of acceptance lies on a deeper level: - Non-Lisp programmers don't like PicoLisp, _because_ it is Lisp. Too many parentheses, and similar nonsense. Too different for them. - Lisp programmers, on the other hand, don't like it either, because it questions everything they were taught (and what they believe) during the last 50 years: Compilers, macros, lexical bindings. Too different for them. That's all, I think. Ok, rant me over :-) No reason :-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
repost
On January 13, 2012 at 5:49 PM Alexander Burger a...@software-lab.de wrote: As I see it, the problem of acceptance lies on a deeper level: - Non-Lisp programmers don't like PicoLisp, _because_ it is Lisp. Too many parentheses, and similar nonsense. Too different for them. - Lisp programmers, on the other hand, don't like it either, because it questions everything they were taught (and what they believe) during the last 50 years: Compilers, macros, lexical bindings. Too different for them. I agree with those two sentiments - those are the deeper reasons. But there is room in the cracks between these two, for instance: - some kind of rapid web development thing very easy to set up, but still easy to extend. It should be so simple non-programmers should be able to get started and, more importantly, could start customizing. Those new users would not even know Lisp was hard, and would like the bumblebee, fly anyway. In fact, Bumblebee is a great name for a web framework. :-) Ideally, it would be possible to install as a CGI on those kinds of cheap web hotels which only support PHP and CGI and come with a wizard for setting it up and so on. Since there is no difference between code and data, the developer could work within the browser and would not even need further FTP access. The logo could be a cute bumblebee ( http://bit.ly/zKzZx6 ) with parens for wings. This is just one idea, there are more if you go #picolisp. :-) // Jakob -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp and its (lack of) libraries
I think I'm the only one except Alex (at least publicly) who actually took time to write a useful/largish web application (vizreader.com). I wanted to see for myself what that would entail. So vizreader is an RSS reader which shouldn't be too difficult, read som XML, store it in a database and then present it and let the user read and categorize it. Some issues I had: 1.) Avoiding ugly urls with a lot of parameters. Something like /read/blog/10/article/5 is preferable to !read?blog=10article=5 My solution was working around by doing a lot of AJAX since that's easier than writing a url rewrite lib, so... 2.) I needed JSON serialization to and from PL, wrote it myself but it's not a releasable library, too little time and energy to make something rock solid (at heart due to lack of capability, a master could maybe do it in a few hours, not me). 3.) Pretty soon it dawned upon me that perhaps as much as 25% of all RSS feeds out there will break the XML lib in PL so a custom more forgiving solution was needed using match (still a work in progress). Languages like Python has probably already dealt with this by already having XML parsers that can handle quite a lot of abuse. 4.) Since Twitter is the micro blogging platform and also outputs RSS I wanted to be able to read it too. However in order to login my users I needed to observe all the rituals as prescribed by something called Oauth and Twitter has its own version called TwOauth which was implemented in PHP, Ruby and Python already so I opted for the PHP version since I was already calling PHP for some small things from PicoLisp (I didn't want vizreader to be dependent on yet another language apart from PL and PHP). Unfortunately the PHP TwOauth needed to be massaged into a CLI version (since I'm calling the CLI version of PHP from PL) since there were a few CGI only things in there. 5.) I ended up downloading a c executable to do porter stemming and calling it through PL (languages like Python already has things like this written of course, you just google and you find). There are probably more but that is what I can think of at the moment. These kind of problems have nothing to do with PL in itself and everything to do with the age old adoption problem, it's like a dating site, the more people who use it the more utility it has and it's a little bit like that with languages too but in a derivative way. In reply to other things that have been discussed above: 1.) Lack of templating is not really a problem, just separate the functions outputting HTML from the rest. The only HTML related problem left then is that it might seem daunting for designers if they have to edit the files, they might also cause syntax errors if they accidentally remove some parenthesis. 2.) For shared hosting PL needs to be implemented as a CGI module to Apache
