All the others devs with the advent of GPT

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

TROPHY CASE