Hacker News new | past | comments | ask | show | jobs | submit login
I'm writing a book about algorithms and Lisp (lisp-univ-etc.blogspot.com)
407 points by ska80 on July 23, 2019 | hide | past | favorite | 53 comments



This seems like the perfect book to round out these:

- Berkeley: Structure and Interpretation of Computer Programs [Racket version] (http://berkeley-cs61as.github.io/textbook.html)

- Duke: Discrete Math [Racket] (https://www2.cs.duke.edu/courses/spring15/compsci230/syllabu...)

Can anyone recommend other core CS books/courses that uses Lisp (or variants) or other functional languages?


Paradigms of Artificial Intelligence Programming (Norvig)


Lisp in Small Pieces


This book is poetry. If you have never seen it, please check it out.


It's one of my favorites along with SICP, CTM, PAIP and The Art of Prolog.


Maybe this will ease my OCD brain of feeling like I need to get get an undergrad in CS to continue by programming career and "earn my stripes". Maybe all I need is exposure to algorithms to feel like I'm more fit for the job. This might do just that. Looking forward to it.


A CS degree is just a collection of topics that you study. Look up the topics, find books, articles, etc on the topics, find a mentor, study the topics, "get degree". The only thing missing are metrics but the metrics aren't the point.

My local university has a book store and the books per course are all there so if I wanted to I could pick up all the books for a CS degree and read um. I could find a list of profs too and I bet if I emailed some I could find one that might talk back.

There's all kinds of ways to go about this :)


I agree, and I've found great resources like TeachYourSelfCS[0] and OSSU[1] to name a few, but there are so many options out there that I am overwhelmed. Reading reviews doesn't help, either. I think I need to commit to one that will get the job done and get me thinking from a CS perspective.

Also, I want to be a great software engineer. I've heard arguments that a CS degree doesn't equate to software engineering in a practical sense.

[0] https://teachyourselfcs.com/

[1] https://github.com/ossu/computer-science


I was a self-taught dev for nearly a decade. Then I got the opportunity to go back for the CS degree. Probably the biggest thing that I got out of it was that I had to work on some things I almost never would have done myself (for me, my low level C/Linux code and networking classes), and it expanded my overall understanding of computers a bit. You can do that yourself, but you have to do it yourself. :)


This is a psychological phenomenon called choice paralysis. My advice: get a mentor. Someone who knows the industry and can remove bad options. OR. Just pick one and forget about it.

Personally my favorite approach a Bring your own idea approach, where you come up with something you want to build and then figure out how to build it, rather than focusing on what's hot or best or correct. You can stripe down CS and focus only on the product development necessary to achieve a release. Gets you coding, which is a good first step in to CS and a better first step in to the industry (CS != business. Overlaps but ain't the same.)

I'm teaching my girlfriend to code and right now she's on the basics: html, and css. She had no idea what to build so I got her to start working on a dictionary of all the things she's learning (essentially she's taking her notes on html, in html). Very recursive and reinforces the knowledge, but (if they're curious) it would naturally segway into "how do I make it look pretty" (which it did) and we're continuing from there.


Metrics give you feedback on your level of mastery.


> Metrics give you feedback on your level of mastery.

Metrics can give you feedback on your level of mastery, but this varies wildly with whoever is providing the feedback.


Yes but they're not the goal.


So do massive FAANG offers.


go visit a campus and just talk to a professor, the usually love the attention.

You can also audit classes for very cheap (or at least it was cheap when i was in school). + I think MIT posts their lectures online for anyone to watch.


The degree isn't important IMO. What is important is a strong understanding of algorithms, data structures, memory, cache locality, your chosen language runtime, etc. Granted, it depends somewhat what you are doing. If your job is to make wordpress templates then it's probably not as important (not to diminish the people working with wordpress & friends), but still an invaluable thing to learn.

The associated calculus & math you'd learn in school for CS/engineering is also worthwhile to learn.


You don't need a CS degree. It might help, but I dunno. I don't have one, and I am a dev. What you do need is what YOU need, which is to say you have inclinations and limitations.

You'll quickly learn your inclinations as you get into programming, as certain activities will be way feel way more interesting & fun to you. I hate studying things I don't need now, which is a limitation, but that no means does that mean I cannot learn those things.

Back to the BSCS thing. The more competitive a job is, the higher the bar to get that job. High paying dev jobs often have the questionably relevant algo questions. 10 years ago it was questions about pirates with gold coins & moving My. Fuji. In 10 years it might be Alan Turing trivia questions. The only thing you can do to optimize for interviewing is to interview, and it helps to be generally competent in your no niche of choice.


So a CS degree is half or even more a math degree. I am yet to find a popular "learn c++ in 24 hours" course that teach you the math needed to think correctly.

The core problem with programming is not the syntax or even the tools, but complexity and abstraction. I.e. programming do not scale well. A 1M LOC program is much different than 100K LOC which is different from 10K LOC, and you need intellectual tools to analyse at different scale.

A non CS programmer usually lack the intellectual tools to analyse problems logically before programming, and jump to code too fast (which is actually encouraged by the "agile" methods, TDD etc).


I think this really depends on the problem. Some problems are best approached by extensive upfront planning while some problems can be better solved by trying the idea out and building a quick prototype.


That's worth a separate thread. I'm digging deep into analysis and combinatorics[0]. But I'm fairly convinced that the market for this is small. Be sure to look at the situation when doing efforts.

[0] I used to find it impossibly hard to work with trendy frameworks and preferred the mental bliss of hard topics. But at one point you need money and being good enough at making a company work can be a good compromise. As long as it's not too hellish.


> I'm digging deep into analysis and combinatorics

Thanks, could you provide some material recommendations?

I'll share one: I've really, really enjoyed 'Graph Theory' by Bondy and Murty (2007 edition): https://www.springer.com/kr/book/9781846289699. Disclaimer: it's much more focused on the mathematical / combinatorial aspects of graphs than on concrete algorithms, although there are some algorithms in there. Some math background recommended.


The classic suggestion is Brualdi, there's also R. Stanley Enumerative Combinatorics http://www-math.mit.edu/~rstan/ec/

but right now I'm starting with basics on S. Gill Williamson Foundations of Combinatorics with Application.

I don't mind pure reasoning, but I need practical programming uses to at some point. (maybe joblessness anxiety showing)

I also have some graph books but since it relies on combinatorics rapidly ..


Combinatorial Problems and Exercises by Lovasz

I don't know much in the way of more advanced expository combinatorics books, other than the more narrow Generatingfunctionology (Wilf) and the already mentioned Enumerative Combinatorics (Stanley).


I warmly recommend Analytic Combinatorics by Flajolet & Sedgewick, freely downloadable at http://algo.inria.fr/flajolet/Publications/book.pdf I like the books you mentioned, but this one I love.


CS isn't anymore of coherent subject than, say, math. And (much like math), the useful/practical parts that'll get you 80%-90% there in solving arbitrary practical problems aren't all that difficult to learn.

Just learning your data structures and how to implement them will serve you very well for many/most tasks.


I would advise to put quite an effort into syntax highlighting, naming, and all the other things that will help an untrained eye to read the code.


He is planning on using LeanPub and they support specifying what programming language code snippets are written in so listings tend to look pretty good.


One thing I really love about Sandi Metz's POODR is how readable the code examples are.


Any Lisp book that is written today owes it to the Lisp community and the rest of the world to write in a modern, safe, and digestible style. One issue with many Lisp books, especially older and self-published ones, is that they contain the author’s pet style or pet idioms, and they wouldn’t fly in a team environment. I think this is especially important because Lisp books are for learning, and if it’s just that much more difficult to Google(/ddg/AltaVista), it will be a frustrating disservice.

Common Lisp has extremely reasonable and regular syntax if you stick to some basic rules and you don’t “flex” the language gratuitously. Written in such a way, the structure would be familiar to the modern Python or Java programmer. Yet the language is a workhorse when the problems get tough or gnarly.

Looking forward to the publication of this book. Seeing introductory algorithms in modern Common Lisp would be a great resource.


Going to push back on this. Lisp is written to be "flexed". And people can and should write it however they want. I think treating students like they're all incapable of googling is utterly infantilizing and nothing about it serves any purpose other than stroking the authors ego. The vast, and I mean seriously vast, majority of programming books waste pages and often multiple whole chapters on treating the user like they can't find the documentation, like they can't reason about different syntactical constructions, and it leaves the learner hobbled and weakened when going out into the real world and trying to read, let alone write, actually code to accomplish a real task. People can cry about Paul Grahams style in ANSI lisp, or Let over Lambda, anyone who can work through either of those books is going to be fine reading Practical Common Lisp (or whatever). Also, finally, Common Lisp isn't exactly known for being a "team language" and the overwhelming majority of projects that I know of were originated by one person. I for one hope the author contributes his work in whatever way will he feels like. Lisp is a liberating language to use, we should write about it in the same way


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


would be nice to have a book with a bunch of algos and pseudocode to implement into any language you see fit.


Over at Rosettacode they already ported a lot of stuff in a huge number of languages.

https://rosettacode.org/wiki/Category:Programming_Tasks

As for books, I liked a lot Niklaus Wirth's "Algorithms + data structures = programs" a couple geological eras back. The book was written with Pascal in mind before the OOP era, but given Pascal's simplicity its examples can be easily translated in other languages. I'd consider more modern books if I knew any; the very few I've briefly skimmed in the past seem either too advanced or too abstract.


That is basically what The Art of Computer Programming by Donald Knuth is and I cant recommend the books enough.


Isn't that pretty much what CLRS is for?


If you don't know Lisp, it would be basically a pseudocode in prefix notation for you.

It takes some time to get used to reading s-expressions, but it's not that hard at all.


Pseudocode isn't perfect though. It's prone to off-by-one errors among other issues. You end up having to describe the specifics of your "flavour" of pseudocode and at that point you've just made a language.. except it's not well thought out and isn't executable anywhere.

TL,DR Just use a language designed for readability, like Python.


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


Something like CRLS? That is fairly implementable pseudocode, but maybe still too hand wavey at times.


It really is; it's irritating that they say it can be trivially proved with induction, robbing me from understanding the crux of the problem.


My thought exactly. Lisp is probably okay (if not even one of the better choices) to get the general message transferred, though.


Can u make a JavaScript version?


Seriously, you should learn Lisp instead.


Exactly. I started going through the SICP book recently, not having used Lisp all that much. After several exercises I see why Lisp is useful for teaching: the syntax doesn't get in the way.

If JavaScript was used, the code wouldn't be as straightforward to write and read and you'd have to spend time going through the language's syntax for the reader (or assume the reader knows it already), all getting in the way of just teaching the algorithms themselves.


Sigh...


The flaws with JS run deep, but it's still the most accessible language out there today. And it does have the most impact. Anybody can make a website.

That being said C/C++, Python and Go are more fun for implementing pure algorithms/data structures as the language constructs are more designed around that.


js as a semantic exercise left to the reader to fix


It's a legitimate question. As much as I love Lisp and prefer it over Javascript, focusing an algorithm book on just Lisp considerably reduces its audience.


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


The audience for a JS book is is also possibly tiny; people who want a JS book already either already have one (or more) and are not looking, or else are likely going to choose one of the many JS books that you didn't write.


>The book will be freely available with a CC BY-NC-ND license.

And yet there is no link to any existing download[sad cat sounds]


> will

That's future tense that you just quoted.

From the first paragraph of the blogpost:

> Now, I'm, finally, at the stage when I can start publishing it. But I intend to do that, first, gradually in this blog and then put the final version — hopefully, improved and polished thanks to the comments of the first readers — on Leanpub.


Also HN didn't keep my edited title. I did add a [WIP] tag ..




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: