vseloved

Got it. Strange, that's the link google search gives me. Also, it shows me price for Ukraine (where I am)

Thanks for the feedback! I recognize the deficiencies of my English writing. Moreover, the current state of the book is, in fact, much-much better than the original manuscript thanks to the efforts of Dr. Robert Strandh, phoe, and Apress proofreaders. As for the residual ugliness - c'est la vie...

sorry, can you elaborate on that? (I'm affraid I didn't understand the question)

there's an interesting recent video on the differences between Cl and Clojure here: https://www.youtube.com/watch?v=44Q9ew9JH_U

Not much. I have summarized all the updates here: http://lisp-univ-etc.blogspot.com/2021/02/programming-algori...

You're quite right that SICP is about the fundamentals. Progalgs is about writing efficient programs. It's for those who already understand the fundamentals.

thanks for the feedback!

In the preface, I discuss a bit the topic of how algorithms are taught in the universities versus how they are actually used. I made a choice to lean heavily towards the "practical" approach. So, from the perspective of a student, this shouldn't be your principal manual, the theory isn't presented in the best possible way, to say the least. (As a manual I'd recommend Skiena, or you can use Cormen etc.) But if you read the book as supplementary material it can give you a different perspective on those theoretical concepts and, hopefully, you'll get more value from studying them as you'll see where it all leads and how you might be using the obtained knowledge in your further work. As for Lisp, I don't think that picking it for any smart student should be a problem.

More of the second: i.e. teach algorithms using Lisp. The secondary goal is to get people more accustomed with Lisp.

Hi, I'm the author.

For those who haven't heard about the book yet: it is a practical description of the main data structures and algorithms in use today. The book is also featuring a presentation of the most important algorithm development techniques, as well a examples of the real-world use cases in each chapter. It uses Common Lisp as an implementation language, and also contains a crash course into the language if you are not yet familiar with it.

For those who have already seen or even read the previous version published on Leanpub, here is a summary of the updates: http://lisp-univ-etc.blogspot.com/2021/02/programming-algori...

As usual, AMA.

Yes, I plan to have a paperback version for $20+shipment. If you send me an email to vseloved@gmail.com I'll include you in the distribution (and send the details on how to pay and receive a copy in a week or two)

thanks for the notice (my typing habit is such that I often don't press the keys hard enough which results in missing letters - easy to see thanks to the spellcheckers when a normal word is misspelled, not so hard for personal names though). Typo fixed

It depends on what you code and how. I hope the book explains some of the approaches and describes the tools that can be used to reduce that difference and avoid a tragedy :)

There's a pretty good overview in this writeup (which is the most recent one): https://ambrevar.xyz/modern-common-lisp/index.html

I examined Union-Find in more detail and found the critical flaw in my description that you were pointing too. Unfortunately, I forgot about it and had a simplified view of this data structure that focused on improving Find but neglected Union. The funny thing is that it was discussed, at times, at group job interviews that I participated as one of the interviewers, and we didn't go these deep to uncover that flaw :) (or, maybe, it was long ago enough for me to forget).

So, I've corrected the Union-Find example to be in line with proper presentation (https://www.cs.princeton.edu/~rs/AlgsDS07/01UnionFind.pdf) removing uf-add in the process. Thanks for the very valuable input.

Surely, that made the example not so bright (as we couldn't reduce everything to a constant-time version with very simple code), but I don't think that the example is inappropriate. It still remains quite simple from the code standpoint. Another reason I picked it was that it didn't require an explanation of any additional data-structure, even, an array, and all the information could be efficiently represented using structs. This still holds.

> This doesn't mention the function slot of the symbol, so one could perhaps argue that therefore the function slot is not meant to be a constant variable

Exactly

> but one could equally well argue the opposite

No, as variables and functions are different parts and there's a more general rule about functions applied to keywords.

Your argument seems to be based on a notion that keywords are something unique and special in CL. They are, but only to the extent that is specified in this section. Otherwise, they are the same as other symbols.

To me, Lisp is not about "forbidden all that's not explicitly allowed", but about "allowed all that's not explicitly forbidden" mentality. And it's, actually, an important trait of the language that makes me value it more than others. So, sorry, I value your opinion, but I think that such things as := need to exist if only to broaden the horizons of people with such opinions :)

Sorry, getting back to the initial point: can you point to a statement in the standard that forbids assigning to symbol-function of keywords or dims it unspecified behavior? I see only this: http://www.lispworks.com/documentation/HyperSpec/Body/t_kwd.... that doesn't state anything like this. Besides these constraints, the keyword symbols are normal symbols so they should abide by the same rules.

thanks for pointing this out

> but then just assumes that computational complexity and O-notation are known.

At the bottom, you can find a reference to the previously published chapters. Complexity & big-O was addressed in the initial. (This is part of a book, all the org details are explained in part 1)

> There is no path compression.

The second variant is path compression. Yes, it may also be implemented in find, but it will make the code more complicated, in my view.

> And then, the uf-union operation: No practical union-find implementation accesses the list of all entries in this operation.

You are correct here. I'll make a change, thanks.

> Also, uf-add seems to allow adding new entries to the data structure but does not add them to the points list

This isn't needed here as it is supposed that we already have the list of points, it's just not arranged for efficient disjoint test. I, actually, had the reference to it, initially, but removed as I considered it redundant. I ll think of adding it back.

This was already discussed in great detail (greater than such minor thing should be) in the comments to the first and next chapter. And, by the way, Lispworks also allows it (see here: https://github.com/vseloved/rutils/pull/39 - a person even bothered to provide a fix to make it work there). So, get over it: this book is not about nitpicking but about trying to explain things in an intelligible and accessible manner. A luxury I didn't always have with these topics...

good point, so, here, it is exactly syntax sugar as, unlike in C++, nothing else except syntax is different from the pointer-based version. Not to mention that, in the article, I was mentioning the general concept that has one (and single) variant, in C and Java, and 2 in Pascal or C++

And here's another quote from this very much upvoted answer (https://stackoverflow.com/a/596750/977052): "A reference can be thought of as a constant pointer (not to be confused with a pointer to a constant value!) with automatic indirection, ie the compiler will apply the * operator for you."

The point of the article is not to talk about low-level specifics of some language, apart, from, maybe, Lisp sometimes. But, surely, not C++ (although, if you could provide a link with a good and accessible explanation of the differences of the 2 styles I'd add it as a reference for further reading). Stil, I don't see that fundamental difference that you mention. If the differences originate from the points that you listed in the original comments can you, please, make the link more explicit? I understand pass-by-reference as being a slightly higher-level and safer C++ alternative to C's direct pointer-based style. But, surely, I may be missing something. But, it seems that the people who answered the SO question I linked are also missing it. For example, here's a quote: "Basically, references and pointers are not very different from an implementation point of view, the main (and very important) difference is in the philosophy: a reference is the object itself, just with a different name."

> Wait, what? Tuples aren't sum types, they're product types.

Thanks for the correction. As I wrote in the introduction, there will be some errors in these beta-version chapters that are published on the blog (as I, obviously, don't have correctors and reviewers), so I'm thankful to all who notice and point those.

> it's totally wrong to say that passing by reference is just syntactic sugar

OK, I'd say that it's still syntactic sugar with some benefits :) But I don't agree that it's totally wrong. Some of the things you mentioned are just side-effects (that you can't do pointer arithmetic or pass a null pointer. Actually, it seems that you can with some jiggling: https://stackoverflow.com/questions/8571078/pass-by-pointer-...). The point I wanted to make is that pass-by-reference is mostly the same thing. It's, actually, quite a confusing topic (as are many C++ solutions) that was not properly presented to me when I stduied it in school, and this book neither tries to present it, but I had to, at least, mention it here as I was talking about different passing styles.

The idea of this book is not be a 10th version explaining the same algorithms. It is as more about how to implement those algorithms for real — production-level stuff, so to say. And pseudocode isn't an implementation language, you will not face the same difficulties, and not get to feel the tools

I would suggest you to read it before jumping to conclusions (as the new chapters will be published). Lisp will not be the main focus of the book, for those who don't plan to use it at work, it may be perceived just as pseudocode. As for Javascript, I believe that explaining algorithms using it is counterproductive as the language has too many limitations that will impede expressing everything I need idiomatically. I'm not saying that you can't program algorithms in JS, but it's not pleasant and productive. Besides, JS is not the language I'm interested in, at all

Thanks for the comment. The style issue will be addressed in the next chapter that is entitled "Crash-Course into Lisp"

it's a classic "worse is better": if doing good is hard, let's do the easy stuff. meh

Thanks for your work on cl-async/blackbird: we also used it in our recent project (and you should have gotten a couple of related requests)! I don't think you should be discouraged though: your contribution is very valuable and surely was noted, just that the whole async approach is, in my view, not in line with the general direction of where Lisp is most applicable, currently (we should admit that it's a niche language). After all, having an evented server means that it doesn't perform a lot of useful computations, most of the work is just serving some kind of existing content. I.e. you could say that the application logic is marginalized and commoditized. And Lisp is the best choice for the opposite cases, those that require and emphasize elaborate application logic and intense computation...

That's not unique to startup - I'd say it's even more relevant to regular "corporate" software development, no? What's unique to real startups (for my definition of "real": the ones that solve yet unsolved technically challenging problems) is: even though you may be better off using a good ready-made infrastructure, that doesn't change the game for you as your competitors also have access to it. While using a conceptually different (more powerful?) toolset might give you an edge over the competitors and a chance to indeed solve the problem you're after. Just yesterday I talked about this: https://www.slideshare.net/vseloved/lisp-in-a-startup-the-go...