Hi Radek, I'm happy the blog helps you! I agree with you that it's hard to find the "important" functions in the beginning. I was very glad when I found the quantitative "Rosetta Code Analysis", I don't know who did it but it was really helpful.
Regarding your documentation proposal with the flags and interactive editing, I'm not able to judge if it's a good idea or not. But from my personal experience, I'm not sure if this would actually solve the problem (for beginners). I think the main beginner's problem is that you actually don't know what to look for, and more flags can be even more confusing. In my opinion, what is really helping is to have tons of examples (and someone to ask). But I guess that's also a matter of personal learning style.. BR, Mia Am 10.09.21 um 15:05 schrieb Radek Svoboda:
Hi, I consider myself beginer. I like your blog (have i read it sooner, i would save my time). PilCon afterthoughts: as beginer I face problem of too big search space for possible answers. I think that your top-down clarification proposal is aimed at that. 60 beginer functions from your blog helps with problem. I think interactive/dynamic documentation is more effective than static one . But I do not efficiently use tools picolisp have for that, yet. Maybe PilCon? maybe valuable proposals: All functions could have flag in properties. [basic] [pilog] [stream I/O] [obscure] [linux native] [destructive] so you can search and limit searchspace. for example: I want basic, stream I/O, not destructive, not obscure. than i read names of functions, than documentation of all searched. Enough flags to limit search to small pool of 7 functions. Documentation could be "live" evaluated and linked with automated tests. So you can add/improve your documentation, and also reduce workload on maintenance. Controversial one: Too much expressivness is double edge sword. It gives you power to do what you want how you want, but also expands search space for answers when writing and reading new code. I am not experienced enough to judge functions, but i think there are too many. Maybe discussion and cleanup? IMHO, all of the above has bigger value than refactoring all pil-core-code which would fit only one person who refactored it. I think it is possible to have multiple working structures of same program to fit multiple people. I do not see very practical way of commissioning it now. Best regards, razzy. st 1. 9. 2021 v 12:34 odesílatel Mia Burger <mia.bur...@gmx.de <mailto:mia.bur...@gmx.de>> napsal: Hi all, I'm Mia, one of Alex' daughters, nice to meet you! I started to play around with PicoLisp a few months ago. So I checked the available resources, and after a while I thought it might be good to have a little bit more "beginner's level" content, with a low threshold and fun to read. Because I feel that a lot of it is already quite advanced (or of rather mixed difficulty), which can be quite frustrating. So we started to put up a blog together. Today I have posted the first article, and there will be one post per day for the next few weeks. If you're interested, feel free to follow! - This is the blog homepage: https://picolisp-blog.hashnode.dev/ <https://picolisp-blog.hashnode.dev/> - And here is the repository with some ideas for structure and content: https://gitlab.com/picolisp-blog/structure <https://gitlab.com/picolisp-blog/structure> I'm always happy about feedback or further inputs - for example, I think it would be really nice to feature some community projects, like Nehal's mind maps. Always open for your ideas! Also, please let me know if something requires further explanation or maybe is even wrong. Wish you a nice rest of the week! Best regards, Mia PS. Also I have to apologize, obviously most of the content is not originally from me but from the community. Sometimes I even copied complete sentences if I liked them. Hope that was ok! -- UNSUBSCRIBE: mailto:picolisp@software-lab.de <mailto:picolisp@software-lab.de>?subjectUnsubscribe
-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
