<xificurC>
FYI I showed my sketch to my manager (who is basically the only other guy doing lisp here, thanks to me converting him) - http://ix.io/1hAm . He was impressed and I answered a few of his questions. The 2 big problems, which correlate, are that picolisp is a niche of the niches and that most devs aren't enthusiastic about their job and software in g
<xificurC>
eneral, making them happier when they can stay with java/js
<xificurC>
I should clarify by problems I mean issues that make using a new language, library etc close to impossible in a larger company
<beneroth>
nice
<beneroth>
yeah I see two basic problems with the popularity of lisp/picolisp/technical well but niche stacks: 1) as you say, some devs are just not enthusiastic about tech and their profession. for them it's just a (good paying) job, not a craft. 2) last century, the contract between company and employee was, that if the employee does a good job, and the company does not somehow run into bigger financial problems, the employee has a secure job he can keep for life.
<beneroth>
This also made it worthwhile for the company to invest into the employee (education). but now the companies want/need to be flexible, and they largely attempt to gain that flexibility by replacing employees. makes investment into the employees (education) less worthwhile. So the contract between employee and company now is not a secure job, but the promise that the employee can do (and maybe learn) fashionable technology on the job, so the employee can kee
<beneroth>
p or increase employability - nice words in the CV to find another employer.
<beneroth>
therefore companies prefer to stay with java, so they (seemingly) more easily find employees, and also to not hurt their attractiveness towards employees by being niche (does not improve the employees CV). and the employees look for a company where they can use and learn what's fashionable (e.g. docker, node.js, Go, js-framework-of-the-month).
<beneroth>
joke is, in the end neither technology choice nor project methodology (agile whatever) does matter much, the big difference lies in the skill of the people involved. but from company-view this doesn't scale well (hard to find/make good people), and from employee-view the work needs to be great visible projects otherwise the entry is no help in the CV.
<beneroth>
also companies prefer to be dependent on Amazon/Microsoft/Google/IBM/SAP (because then they can point at other victims and feel less bad) instead of being dependent on having to find/create picolisp devs.
<xificurC>
beneroth: you summed it up pretty well :) The sad part of it is that today's technology choices make development orders of magnitude harder, making this whole lets-stay-with-java-so-we-can-hire game funny since you wouldn't need that many devs in the first place
<xificurC>
if I compare with what I wrote now in picolisp - database definition, backend and frontend logic, all in one language and one file of 55 lines
<xificurC>
to do the same with a typical SQL for database, Java for backend and JS for frontend I guess we would be closer to 500 lines
<xificurC>
and it's not just about the dev but about the ops too
<xificurC>
it's pretty simple to fire up the picolisp version, just have pil installed and start with 1 simple command. For the typical scenario? Setup a big sql database and run it, set up java, compile and run it, set up frontend and distribute it via the backend
<xificurC>
and for development you'll need to set up *a lot* of things too - something to browse the DB and query it, something like eclipse or intellij to run your java code and for it to connect to the database, some unholy combination of the latest&greatest JS tools. The list goes on
<xificurC>
I can see the first 10x factor
<beneroth>
I believe the 10x dev thingy is nothing biologically, but a few principles and much self-discipline
<xificurC>
I think you need to remember both sides. You will be 10x slower if you decide to run the marathon in high heels
<beneroth>
xificurC, often people prefer to do many dumb steps instead of a few clever ones. you can be blamed for what goes wrong when you took the clever route, but on the other route you can blame the nature of things. also when it takes you longer and is more complicated you can feel more expert, and last but not least you get payed for time spent looking like working, not for results.
<beneroth>
(in direct employment. it's different with contracting work).
<xificurC>
true
<xificurC>
sad, but true :)
<beneroth>
:(
<xificurC>
I find myself spending a lot of time looking for the right tools because I don't want to waste too much time on learning the wrong ones
<beneroth>
yeah. thats something all the people in this community have in common, else they would not be here :)
<beneroth>
self-selection.
<Regenaxer>
Hi all! Interesting talks! :)
<xificurC>
what is your bus factor Regenaxer?
<beneroth>
1
<beneroth>
hi Regenaxer :)
<Regenaxer>
bus factor?
<beneroth>
how many people have to get under the bus before the project/business/whatever is doomed
<Regenaxer>
haha, yeah. Well, we are 2 but the projects are rather separated
<beneroth>
xificurC, well picolisp will live on in any case. we have a tiny but dedicated community. and MIT license, so rights are also no issue.
pierpal has quit [Quit: Poof]
<xificurC>
yeah, but one needs to understand it in order to modify it :) Last time I checked I think the whole codebase is around 30k LOC which isn't all that big
<beneroth>
T
<beneroth>
two levels: picolisp and pil asm
<beneroth>
we're a number of people who are fluent on the picolisp level and can debug and modify it when necessary. a few of our community already dabbled with pil asm (it is well commented in the source), but there we still need some more people to get fluent beside Regenaxer.
pierpal has joined #picolisp
<Regenaxer>
Yeah, the more the better to be on the safe side
<beneroth>
and Regenaxer tells NO to much stuff. this feature has to be preserved to ensure stability and compatibility :)
<beneroth>
xificurC, no reason to expect Regenaxer gone soon, except for a sudden unexpected bad luck tragedy. but that can always happen. with bigger companies it might be more unlikely that they die (takes decades), but more often than one would think they change opinions and suddenly shutdown products (Google, Microsoft, Oracle, ...) or they get bought by another company and might get closed or completely changed.
<beneroth>
if you want to minimize dependency, MIT license and capable people in your own organisation is the best way.
<beneroth>
if you want to minimize short-term costs it probably isn't. Though minimizing long-term costs are another side entirely.
<xificurC>
this was just a curiosity question to be frank. I wouldn't mind maintaining the language if my life income would come from projects running on top of it
<beneroth>
that's how Regenaxer did and does it.
<beneroth>
and I'm working on getting there, too
<xificurC>
getting where exactly
<beneroth>
I can think of at least 4-5 people who would surely be capable and probably willing to keep picolisp alive if Regenaxer would be missing.
<beneroth>
xificurC, getting from contracting/freelance company to software product company, software based on picolisp
<xificurC>
beneroth: you mean instead of taking up projects to work on with picolisp you want to create a product based on picolisp and try selling it?
<beneroth>
both of this
<beneroth>
instead of working in whatever the client demands
<xificurC>
both? So right now your main income isn't from picolisp apps
<beneroth>
I do a lot legacy stuff
<xificurC>
legacy = cobol? :)
<beneroth>
so far I was lucky, no cobol ^^ but Fortran. and C stuff and messy databases.
<beneroth>
currently my main income is from contracting work where I work with whatever technology the client has/demands. I have some picolisp apps running (for 3 years now), some which don't generate much income beside a small hosting fee, some which give some feature wishes so a bit of a side-income. not enough to stay afloat yet, but the picolisp side of my business is growing.
<beneroth>
and in parallel I work on a software product based on picolisp. not sure yet how much I will sell products/projects based on that software, or how much the software itself will be sold as product.
<beneroth>
xificurC, what kind of software are you working on?
<xificurC>
beneroth: I am a small mouse of a mid-sized company (200-250 employees). The applications being developed are mostly java+js, many are starting to use mongo and some are using a new "framework" written in groovy. I am part of a small team (~6) that is responsible for internal tooling and infrastructure. Most importantly we package the applications
<xificurC>
in docker and take care of shipping it where needed
<xificurC>
and I personally take mostly care of the internal tools that drive the tools of most of the devs, that glue together project definitions and IDEs and deployment tools etc
<beneroth>
interesting. tooling is good, usually companies are less sensible to tech choice for tooling than for customer or productive stuff. so maybe there you can sneak some picolisp in :)
<beneroth>
if you are not so bound to windows. then it gets a bit more difficult, as picolisp pretty much expects a linux underneath it.
<xificurC>
well I convinced my boss of the power of lisp and he rewrote the configuration management tool we were using in common lisp
<beneroth>
why not clojure?
<beneroth>
if you run pretty everything on JVM anyway?
<xificurC>
as a test kind of. Now it's underneath every project :)
<beneroth>
hehe, nice
<xificurC>
these are mostly command line tools
<xificurC>
feeding eclipse with correct java parameters, feeding docker with correct parameters, starting off programs with correct configurations etc
<xificurC>
clojure has horrible startup time for do-it-and-die script-like programs
<xificurC>
sbcl (once cached) starts in like 30 ms
<beneroth>
arguments for picolisp
<beneroth>
it's tiny, so startup is quick
<xificurC>
it was considered, but 1) too niche, 2) lot of the configuration management is about working with strings and picolisp isn't very string-manipulation oriented
<beneroth>
2) partly true, though when treating strings as streams, working on them with (from) (till) etc. is very powerful. for parsing / rule-based string building, a small FSM can be implemented using (state)
<beneroth>
you can use (pipe) so you can push strings into a pipe buffer and treat it as a stream
<beneroth>
I don't want to talk into something not fitting your use cases (you know that better than me), just trying to give ideas and point out options :)
aw- has joined #picolisp
<beneroth>
hey aw- !
<aw->
hi
<beneroth>
you do configuration management (building config files etc) with picolisp, right?
<aw->
yep
<Regenaxer>
Hi aw-
<Regenaxer>
singa, tankf33der: Finally I fixed the bug in co/catch!! Only a single line, updating a single link was missing
<tankf33der>
cool.
<Regenaxer>
I hope there are not more bugs
<tankf33der>
i will play.
<Regenaxer>
At least singa's test case works now
<Regenaxer>
Cool, thanks!
<singa>
You've made my day, Regenaxer!
<Regenaxer>
:)
<xificurC>
beneroth: strings could be handled, although I still feel like they are a second-class citizen in picolisp :) The bigger issue is 1, that a problem cannot be googled and found on stackoverflow :)
<Regenaxer>
The simple form of the test case was:
<Regenaxer>
(de foo ()
<Regenaxer>
(co "html"
<Regenaxer>
(catch "err"
<Regenaxer>
(println 'OK)
<Regenaxer>
(yield)
<Regenaxer>
(throw "err") ) ) )
<Regenaxer>
(foo)
<Regenaxer>
(do 3 (foo))
<aw->
beneroth: why?
<Regenaxer>
One (foo) on top level, the next in another stack position
<Regenaxer>
Only this case crashed, cause the pointer to the co frame was dangling
libertas_ is now known as libertas
<tankf33der>
Regenaxer: all co tests passed. issue closed.
<singa>
Is there a new release of pil with this fix, or I need nightly?
<beneroth>
aw-, xificurC works in a similar field than you (as far as I understand) :)
<tankf33der>
singa: just download software-lab.de/picoLisp.tgz
<beneroth>
and you can ask here in IRC, during EU daytime you usually get quickly good help.
<beneroth>
Regenaxer, great!
<Regenaxer>
I'm happy if this is fixed now. Coroutines are about the most nasty parts in the interpreter core
<beneroth>
aye, good achievement
<beneroth>
so it was all a nasty little sloppy mistake?
<Regenaxer>
yes, forgot to fix one more pointer
<beneroth>
well this was one of the newer and not so widely used features.
<Regenaxer>
Never noticed, as it is bad only when the coroutine runs in another part of the stack after a (yield)
<aw->
beneroth: unlikely
<Regenaxer>
yes, indeed
<aw->
beneroth: details?
<beneroth>
aw-, only very roughly
<Regenaxer>
Plus: Uses catch and throw both inside the coroutine
<beneroth>
tooling for config management, glueing other stuff together, deployment management. my point was xificurC found picolisp not suited for building configs because of the string-oriented nature of the task. I liked to point out that you use it for such a case.
<beneroth>
Regenaxer, nice. whats the behaviour with a catch outside the coroutine? ignored?
<Regenaxer>
Yes, eg a throw to the outside of the coroutine worked
<beneroth>
oh nice
<Regenaxer>
The catch frame inside the coroutine was not updated
<beneroth>
ah
<beneroth>
I see
<beneroth>
many different edge cases to test
<Regenaxer>
yes, this is the problem
<xificurC>
beneroth: bear in mind I was talking about my manager's points, not mine. I wouldn't worry about not finding answers on SO. Neither does he (to some extent) but if others were to contribute to it, they would
<aw->
beneroth: hmmm.. actually I use Ansible for that stuff. I only use PicoLisp to generate/parse JSON files, and to call Ansible and to run other tasks in the background
<beneroth>
xificurC, I understand :)
<beneroth>
aw-, ah okay. sounds reasonable. no point in re-inventing things.
<xificurC>
ah, ansible, the yaml-programming language :)
<aw->
xificurC: ansible works just as fine with JSON
<beneroth>
yaml is dying afaik, no?
<xificurC>
we use it here as well, but I'd rather invent a new wheel to be honest :)
<aw->
xificurC: waste of time
<xificurC>
although we don't use it as it is supposed to be used - to run the yamls across a cluster of machines
<aw->
xificurC: what company? what business?
<beneroth>
it's funny to what length people go to re-invent s-expression notation. often because they never heard of lisp. or because they try to achieve it without parens. using long xml tags instead, even less readable ^^
<xificurC>
I would say using ansible to set up *a* machine is a waste of time. If the question was many machines all running different OSes etc I guess there would be a point
<aw->
you build virtual machines using ansible local?
<beneroth>
xificurC, jumping stilts on the main page illustration, haha nice
<xificurC>
gotta go afk now, will be back later
<beneroth>
I got some of the brand pictured there
<beneroth>
ok cu xificurC :)
<beneroth>
nice talking with you
<xificurC>
aw-: no, it was used here to set up the machines locally
<aw->
oh i see
<xificurC>
something a shell script would do with less hassle, LOC and effort
<aw->
yes, until you need to perform error handling
<xificurC>
it was used so we would learn the thing and perhaps use it later for what it was designed to do
<aw->
yeah that's valid. i don't see Ansible as a holy-grail, it's fine if you're willing to deal with the crap that comes with it ;) but i wouldn't replace Ansible with a shell script haha. Replace with a *Lisp makes more sense. Any Lisp, doesn't matter
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #picolisp
<xificurC>
aw-: I mainly don't like what I call yaml-programming - trying to fit a domain of problems into something "declarative" only to later find you still need conditionals, loops, variables etc. and wind up with a new proramming language embedded. A library makes much more sense
<beneroth>
yeah, this way you re-invent s-expr and lisp badly
<beneroth>
picolisp uses tag bits within the pointer (see @doc64/structures)
rlp10 has joined #picolisp
<Regenaxer>
Thanks beneroth! Interesting article
<Regenaxer>
Some implementations are indeed awfully complex
<Regenaxer>
"16 pointer types of objects in the 940 LISP" :D
<Regenaxer>
horror ;)
<beneroth>
schlimmer geht immer ;)
<Regenaxer>
exactly!
<beneroth>
Regenaxer, how efficient is (state) ? probably more efficient instead of having multiple (if) after another checking the same thing? or better putting the code shared in multiple cases/states into another function and calling it, instead of implementing a FSM?
<beneroth>
what's your style?
<beneroth>
I feel like I should use (state) more
<Regenaxer>
I think the efficiency does not differ much
<Regenaxer>
But it is convenient in some cases
<beneroth>
ok, reworded question: FSM or additional function (and calls) to deduplicate code only used within a little part of the code ?
<freeemint>
This is cool, but the author could sell his idea better. It took me a while to figure out what a Penti Chorded keyboard even is. The video linked at the very bottom shows why this could be useful: https://www.youtube.com/watch?v=z_01ha1uS6Y&feature=youtu.be I wish the author had explained at the start what problem this solves rather than launching right into an explanation of how it works.
<freeemint>
I'd like to notice an important thing: with this keyboard, one does not move the fingertips at all. The only motion required is press / release. This is a great quality when hands are busy with something else, like holding a bike's handlebar, or an aircraft control rod. It's also likely a good setup for some smart glove type of input device, where there are no keys to press but finger motions are detected. If fingertips are all
<freeemint>
i did not know that pic exist tankf33der
freeemint has quit [Quit: Page closed]
stix has joined #picolisp
stix has quit [Quit: stix]
alexshendi has quit [Read error: Connection reset by peer]
pierpal has quit [Quit: Poof]
pierpal has joined #picolisp
alexshendi has joined #picolisp
mikey_ has quit [Ping timeout: 256 seconds]
alexshendi has quit [Read error: No route to host]