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 [email protected] 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