Programming Algorithms: A Crash Course in Lisp | Hacker News Reader

Programming Algorithms: A Crash Course in Lisp

lisp-univ-etc.blogspot.com

135 pointsdeepaksurti28 comments

> It is much easier to explain Lisp if we begin from a blank slate.

More so than any other language I know of, Lisp's reputation precedes it. Everyone seems to know all about Lisp. It's remarkably rare to find people who genuinely want to explore Lisp the way they do other (newer) languages, with no preconceptions and biases.

It also seems people do things less and less out of sheer (scholarly) curiosity these days.

You mean the Greedy Ghost [1] has swallowed up everything in it's path? I agree. I've almost got my ass kicked on a few interviews for daring to say I do Lisp in my free time. "Lisp?! What the f* do you wanna do with thaaat?!" was more or less the answer that I've received. If it doesn't bring any more $$$ in your pockets you're just wasting your time.

[1] https://www.rt.com/op-ed/465466-europe-tourism-greed-profit/

I earn money for working in Clojure. And I feel it provide a huge advantage.

I do Haskell in my spare time too. Once you’re used to FP, going back to imperative languages feel like a terrible regression.

at best it feels like your compiling FP idioms onto classes like a compiler

I wanna earn money doing FP work, too!

Of course, Common Lisp spoiled me beyond words. I've tried OCaml the other day. It might be a good language, but I can't seem to make it integrate nicely with the Emacs workflow that I was used to from Common Lisp. You need ;; at the end of your expression when in the REPL, but not when building a standalone app in OCaml. When compiling it's considered bad practice to put ;; But without it, the REPL doesn't know where the expression ends. Or something like that, anyway.

Same story with Prolog. It might be a good language, but there are all sorts of special cases and exceptions when working with it interactively. I've gotten so much used to working interactively, to have a live, one-on-one honest conversation with my language and environment that languages without it seem brain-dead somehow.

I agree with your "terrible regression" comment.

Try https://github.com/triska/ediprolog for a great interactive Prolog mode for Emacs. Much better that SLIME (as I remember it from briefly playing with it ten years ago): There is no notion of moving code from your edit buffer to a REPL, the code in your edit buffer is your program. Queries are also part of your program (using special comment syntax) rather than entered in a separate REPL and lost when you close that.

I think Tuareg-mode also makes the OCaml part a lot less painful. It's a bit unfair to compare Lisp used with tight Emacs integration to OCaml used seemingly without the corresponding integration.

OCaml is pretty sweet too, but I think it strikes a different balance. You end up with something more static of course, but I've found it to be quick to compile, and quick to run.

You still can't compare to the SLIME experience for CL of course, though tools like Utop are nice. That and a few other add-ons try to fill some gaps.

Same here, also Clojure.

I don't know if I could ever going back to an imperative language full-time, I think I'd feel very hampered.

I once worked at an organization where we programmed in Common Lisp. Several other programmers in other parts of the outfit didn't want to join our team because they thought having Lisp on their resumes would hurt their future job prospects.

My response was if you really think about life that way, you wouldn't fit our team, and if those are the kind of employers you'd consider working for, you really wouldn't fit our team.

I wonder what made them think being a lisp programmer would be off-putting to employers.

Maybe fear of getting pigeonholed as a head in the clouds academic type who does little but proclaim the superiority of LISP and chide people for not understanding macros? Or some other LISP-based stereotype (that’s for AI, right? LISP is hard to read, I don’t know why you deal with that BS, etc.)

Speech therapists cons tand dotted pears and parenthesis.

I expect it was because they considered Lisp "old" and that employers might also.

I would say, the main problem was that those people were overly concerned with what they will be stuffing into their resume next.

Anyway, in a resume, you can write about what was accomplished: "designed, implemented, maintained and documented such and such a system, of such and such size and scope, deployed in such a such are role in such and such customer sites."

Great article, thank you. As recently as 10 years ago, I was still sleeping in hostels or on benches in Europe while traveling around in the crusty student/bohemian style. Just this year, I visited again (I live in the US now) and was shocked by just how commercialised some cities have become compared to how I knew them before (and they were still very commercial even then).

Don't know why you're being down-voted. You're welcome and thank you for your confirmation regarding the article's contents.

Yes, I would consider Lisp as a big no-go in a resume, if I was looking for a programmer (developer isn't the right term in this context) doing boring and repetetive stuff. Lisp can really spoil one for this kind of work.

Would I look for a developer though, who should solve difficult problems elegantly, a Lisp background would be a huge bonus. Even if the actual work is done in a different language, Lisp gives an ideal introduction into many fundamental concepts. For being a complete developer, one should have learned a variety of programming languages which are based on different concepts, as there isn't one one and only language. Lisp certainly belongs onto the list of languages to learn at least a bit.

But then, can't you do "boring and repetitive stuff" faster with higher order functions, metaprogramming etc.?

I'm not a professional developer and I occasionally look at it as a potential career (I have a plausible history with programming and have been called to interviews), but the idea that most programming is "repetitive" boggles me. I mean, if you literally have to type things over and over, can't you program it somehow?

Sorry, that was not meant entirely seriously. Of course, a good programmer would try to reduce the amount of (boring) work as much as possible and high level programming languages like Lisp can help alot with that. But there are also programming jobs, where you are set for a certain programming language and are forced to do pretty boring stuff all over again - as the job requires it. These jobs should be avoided by those who like exploration and interesting stuff :).

Can you give me some examples of repetitive (or very boring) kinds of programming work that's commonly demanded?

(This isn't a skeptic take, I've been really pondering whether coding is for me, since taking the next step in my current career path requires an upgrade in "soft skills" that... )

In banks, a lot of the important operations are on entrenched/Legacy systems (eg mainframes) or vendor/cots solutions.

Therefore for some developers in a bank, a lot of work tends to focus on shovelling data around the bank in a myriad of formats to interact with these systems, or get data in and out of databases.

This a thousand times. If you're writing something over and over again in slightly different guises, you're either doing it wrong or using poor tools.

I've had one interviewer laugh in my face when I told her my favorite language was Scheme.

I'd have lost all respect for them as a developer in that moment.

I bet she was like "Scheme?! But can it do websites?"

It comes hand-in-hand with the rapid growth of people entering development with a commercial mindset. This has been a thing ever since there was a software industry, but as the profession has grown farther away from academia it's only gotten more prominent. For this group, the point of it all is not to do anything particularly principled or learn it as an art, but to run a grift or a hustle where everyone is role-playing and the code is the means to the ends, not the end in itself: Posture as a good developer, focus on the conversation, on selling yourself and selling a solution, then back it up with some legitimate skills or a very clever workaround as needed.

I point to the popularity of Youtubers like Joshua Fluke[0] as a good example of the mindset and how it's articulated. It isn't a "wrong" way to do things - this mindset is mercenary, geared to go up against every exploitative owner and manager and skillfully negotiate them into a fairer valuation of your labor - and it can result in decent software and happy clients - but it's also cynical and assumes low trust, and as I get a bit older I do see it as being a bit like choosing an alignment in a Dungeons & Dragons character: The "lawful goods" and "chaotic evils" tend to cluster and support each other in their own ways, it's just that at the start of your career you can't tell them apart yet, and you don't know which way you'll ultimately go, but the work you end up doing over the long run is determined as much by your approach and mindset as any specific skill.

[0] https://www.youtube.com/user/Tychos1

It's even easier to explain Lisp if we start with not a blank slate, but a slate that already includes the understanding of a Von Neumann processor that shuffles words between memory and registers, has a stack for parameter passing and temporary storage, and a heap for enduring objects which are referenced by pointers.

Exactly. Lisp rule could be shortened to minutes to explain. From SICP videos for HP, by Hal Abelson:

> Lisp is easy to learn... just as you can teach someone all the rules of chess in a few minutes. But of course, it takes much longer to master those rule... how do you exploit those rule to become a master player.

Reply on news.ycombinator.com