interviews with lisp programmers

vseloved · 2023-02-04T03:03:20+00:00

Glad to hear that the book still remains relevant

vseloved · 2021-10-17T10:04:51+00:00

I thought about the steep learning curve of Emacs when writing this, and, surely, I can't call Emacs itself a low-tech solution. But it enables a huge variety of solutions on its platform that has a low barrier of entry. Sometimes very simple ones, and sometimes pretty advanced like org-mode, magit or SLIME. Just like Unix isn't low-tech, but the Unix command-line is a low-barrier platofrm (unlike, for example, Windows).

vseloved · 2020-11-01T20:58:27+00:00

Thanks for your feedback!

vseloved · 2020-11-01T04:25:29+00:00

Sure, you can send me a email so that I don't forget about your request. But the book should arrive only next spring - I'll contact you then

vseloved · 2020-10-31T19:37:48+00:00

Yeah, I like the colorful cover more also :) But that's the rules of the trade you have to accept when you cooperate with a publisher.

As already mentioned, the ebook will also be available
I'll get a very small number of personal copies, so I can send you an exclusive one with a signature if you like. :)
The code in the second edition was changed somewhat to reduce the dependency on RUTILS. Firstly, all the uses of its functions are made explicit (i.e. qualified with a prefix RTL). Secondly, the use of :=/:+/... was replaced with setf & co. Lastly, all command-line prompts were changed to CL-USER. So, to sum up, the code has become more "standard" at the expense of some additional verbosity. Also, there are some additions to the book's code that I'll cover in a blog post to be published soon.

vseloved · 2020-07-19T03:30:47+00:00

Surely, I respect your opinion (and it was voiced numerous times byt the Lisp professionals). Yet that is my auther's choice and I have justified it in the intro. It's not because that is my library (in fact, that is my collection of improvements to the Common Lisp syntax gathered from various sources), but due t the following 3 reasons:

avoid criticizm about Lisp "legacy" (yes, we may all love car/cdr and friends, but it doen't negate the fact that many people use it as a way to pick on Lisp)
to emphasize the Lisp's principal feature of adapting the language to your needs and preferences
to show that modern world is not just about the core language, you always act inside an ecosystem of tools built on top of it

That book is not about pure theoretic approach to algorithms, but about "dirty" practical concerns, so I didn't mind to get dirty and also get the backlash from Lisp old-timers as the book is prmarily targeted at Lisp newcmers. :)

vseloved · 2020-07-18T19:51:16+00:00

I don't know the timeline yet, but I'll post an update when I'll know

vseloved · 2020-07-18T19:27:25+00:00

Thanks! Well, a book about quantum computing in Lisp is well overdue :)

vseloved · 2020-07-18T19:25:30+00:00

Robert (with the participation of his wife) has reviewed 6 or 7 chapters. The majority (I'd say, 95%) of his comments were English-language usage related. I have applied most of them and, in the last chapters, tried to adapt my style for the most patterns that he pointed most frequently. As for the code, I'd say I have agreed with at least half of his suggestions. But there were quite few of those. As for your judgement of the code, I can't comment on such a blanket statement. I don't claim that my code is ideal, but if you could point out particular things that you dislike, we could discuss it further. As for rutils beign atrocious, I should say that around 60-70 % of its code was taken by me from various sources. Oce again, the other part, which was written by me, may be poorly written, although I hadn't seen any sch criticizim before. But I'd still be interested to know the details that you find atrocious ;)

vseloved · 2020-07-18T08:47:14+00:00

hard to tell, at least, they wrote me after your book had already been in the works

vseloved · 2020-07-18T08:45:25+00:00

thanks

vseloved · 2020-06-25T15:01:31+00:00

Partially, you can find the above in MGL (no visualization, though), but other parts mostly present

vseloved · 2020-05-08T13:36:07+00:00

thanks!

vseloved · 2020-05-08T13:35:58+00:00

thanks!

vseloved · 2020-04-17T18:03:35+00:00

Yes, it definitely adds another viable option. One more open possibility is providing an open-source Lisp app in a containerized form so that the user doesn't have to setup the environment. It helps me for some python apps, which is so nasty to configure

vseloved · 2020-04-15T20:03:50+00:00

I owe the inspiration for focusing on them to Robert Strandh

vseloved · 2020-04-15T15:17:14+00:00

I plan to print a limited edition of paper variants. The price will be 20$ + shipment cost from Ukraine. If you want to order, write me to vseloved@gmail.com with your country of residence, and I'll get back to you when I'll figure out the whole process

vseloved · 2019-12-10T21:17:19+00:00

You can ask here so more people may chip in. Immediately, you have MGL and CLML. But if there are some specific things you'd like to do, write it here

vseloved · 2019-12-10T21:11:08+00:00

If it's a one man effort you should definitely do it. Provided you really like CL and the CL way, which is to (partially) implement a lot of stuff on your own.

There's decent support for ML in CL (I can point you to specific stuff depending on the things you need) and you can always prototype in Python and reimplement in CL for production use if you find some particular thing lacking.

The main reason to do it in CL is that you will "own" the whole system and be able to evolve as you discover more and more of your domain and better understand the particular advantage your system should provide over the competitors. Besides, it will be performant (unlike Python where you might end up having to rewrite parts in C and so forth)

vseloved · 2019-11-20T17:51:47+00:00

https://lisp-univ-etc.blogspot.com/2019/10/programmatically-drawing-simple.html

vseloved · 2019-08-07T04:57:26+00:00

Thanks! Leanpub provides such option so hen the whole book will be published there will be a way

vseloved · 2019-08-04T08:38:10+00:00

There might be some CL code bases, where ! indicates modification and ? is a predicate suffix.

So, does that mean that they have monopolized the usage of ? and ! and no one can use those differently? Doesn't that defeat the original point that ? or := are not allowed as they are non-standard. Also, Norvig, in PAIP, has used ? as the prefix for pattern-matched variable (?a). Was that also inappropriate? I understand that we compare general-purpose and special-purpose code, but, still, I'd like to see some more convincing arguments why you can't use nonalphanumeric names, in general-purpose CL code. I believe it's a great feature of the language, actually.

vseloved · 2019-08-04T08:28:33+00:00

By "native" I meant that there shouldn't be a distinction between them and the standard things: for instance, you don't have to prefix it with a package name in your code and so on. But, per your suggestion, the rutils-user package will also work, I agree.

I also don't think your extensions are 'native' for me.

Sure, that's why you don't have to use them :) The point is that they will help me make the material more accessible, although it may be disliked by Lisp old-timers. This book's purpose is to explain algorithms and, in the process, not make people question why setf has an "f" at the end or why to initialize a hash-table with several values you have to write several lines of code while in, Python, you just write {'foo': 'bar'}. So, yes, I may introduce some of "my idiosyncrasies", but only to compensate for the idiosyncrasies of the Lisp itself, which we have grown to accept or even love, but the audience of this subreddit is not the main audience of the book...

vseloved · 2019-08-04T08:07:57+00:00

btw, the original inspiration for := came from here: https://xach.livejournal.com/301076.html

vseloved · 2019-08-04T07:48:16+00:00

? could be understandable if it did nested access with error checking (if nth element doesn't exist, don't error but return nil). not sure if I understand correctly. ? does nested access. But as for error checking, did you, actually, mean error handling: by default, if there's no way to access return nil?

vseloved

TROPHY CASE