Zach Beane

Common Lisp, specifically SBCL. Most popular choice (outside of Clojure and Emacs Lisp?). That's the easy answer. You'll encounter more libraries and online answers/resources which will help any growing pains. Quicklisp is used for package management and quickproject is a great starting point to get you writing lisp asap. Practical Common Lisp is a great introduction to the language. https://www.quicklisp.org/beta/ https://xach.com/lisp/quickproject/

Fun fact: the name is a Pulp Fiction reference :) https://www.xach.com/gg/1997/1/profile/1/ "It took us a little while to come up with the name. We knew we wanted an image manipulation program like Photoshop, but the name IMP sounded wrong. We also tossed around XIMP (X Image Manipulation Program) following the rule of when in doubt prefix an X for X11 based programs. At the time, Pulp Fiction was the hot movie and a single word popped into my mind while we were tossing out name ideas. It only took a few more minutes to determine what the 'G' stood for." It's a shame how so many people these days want to change the name and destroy such an early and enduring example of gay representation in Free Software.

From https://www.xach.com/naggum/articles/[email protected] "if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them. those are the ones that matter."

Starting from classes and describing generic functions as a way to send messages is pretty backwards for CLOS. CLOS is best used primarily by defining a protocol with generic functions, then using methods and (optionally) classes to implement the protocol. http://xach.com/lisp/jrm-clos-guide.html has a copy of Joe Marshall's "Warp Speed" CLOS guide.

It only seems weird in so far that you are ignorant (aren't we all?) of the generic function approach to object orientation. In the message passing approach you dispatch based on the type of the first argument to the method. Because it would be redundant to explicitly write down the argument it is commonly syntactically elided (though not fully in Python) and you get coupling of the methods and the object. This is not a fundamental property of OO but accidental feature found in most OO languages. In the generic function approach, the dispatch is extended so one can dispatch on the type (among other things) of (ideally) all of its arguments. Julia follows this approach afaik and if one is familiar with the generic function approach it is not a controversial claim at all. Erik Naggum explains it here in more depth: http://www.xach.com/naggum/articles/[email protected]

There are whole lot more supplementary rants: http://www.xach.com/naggum/articles/search?q=xml In particular: http://www.xach.com/naggum/articles/[email protected] with key words being "Whather what you are really after is foo, bar, or zot, depends on your application.". His articles on SGML are mandatory reading too. Several years ago someone posted these links and it opened wonderful world of Lisp to me. Not the language per se (there are many languages) but whole another Universe of how things could be done. I swear I jumped on the chair reading every page of CL standard, how brilliant it is on every level to C. Eventually it led me to rethink attitude to C and Unix in general, core parts of which I despise now. So here am I returning favor, maybe someone will follow these links too. Thank you, Erik. Rest in peace.

The best argument I have seen in favor of Scheme being something other than a Lisp is by E. Naggum: "In the Algol family, the symbol table is a compiler construction. In the Lisp family, the symbol table is a run-time resource. In this sense, Scheme is a member of the Algol family and not a member of the Lisp family." (http://www.xach.com/naggum/articles/[email protected])

Some of Erik Naggum's best flames were with Xah Lee in mind. http://www.xach.com/naggum/articles/search?q=xah&sort=of

Vecto (http://www.xach.com/lisp/vecto/) in Common Lisp is excellent for this sort of thing (see http://common-lisp.net/project/adw-charting/, which uses it).

Yes, I cited it an above comment: https://www.xach.com/gg/1997/1/profile/1/ Here is the full quote: > > Your home page says that you created GIMP to address the lack of free or inexpensive Unix graphics tools. How did you guys actually get together to tackle this? Was it like in Blues Brothers? Were you on a mission from God? > Spencer was my brother's roommate for four years. (He's been my roommate for the past six months). So I knew who he was when we decided to take the compilers course here together. Big mistake. During one of the impossibly boring assignments we decided we wanted to do something which wouldn't suck. The idea of doing the GIMP actually fell out fairly naturally. > It took us a little while to come up with the name. We knew we wanted an image manipulation program like Photoshop, but the name IMP sounded wrong. We also tossed around XIMP (X Image Manipulation Program) following the rule of when in doubt prefix an X for X11 based programs. At the time, Pulp Fiction was the hot movie and a single word popped into my mind while we were tossing out name ideas. It only took a few more minutes to determine what the 'G' stood for.

mikolajw> I am not aware of any evidence that there was an intent to offend. The only source for etymology I know here is an old interview with one of the original developers where he said that he blended the words GNU and Image Manipulation Program, and soon afterwards realized that he heard that word before in a film. That's wrong on every count. The primary source is Peter Mattis' own words in the GIMP Gazette interview, January 1, 1997, by Zachary Beane: https://www.xach.com/gg/1997/1/profile/1/ Mattis> "It took us a little while to come up with the name. We knew we wanted an image manipulation program like Photoshop, but the name IMP sounded wrong. We also tossed around XIMP (X Image Manipulation Program) following the rule of when in doubt prefix an X for X11 based programs. At the time, Pulp Fiction was the hot movie and a single word popped into my mind while we were tossing out name ideas. It only took a few more minutes to determine what the 'G' stood for." So the sequence was: IMP (rejected) -> XIMP (rejected) -> Pulp Fiction inspires "GIMP" -> they reverse-engineered "General" as the G. The Pulp Fiction reference was the generative act, not an afterthought. The GNU backronym came later. Same interview: Mattis> "the GIMP originally stood for General Image Manipulation Program, but has since been dubbed GNU software by Richard Stallman (with our agreement). Spencer and I decided that GNU Image Manipulation Program is a better usage of the 'G'." He didn't…

I think this article (of sorts) is definitely helpful for onlookers to Common Lisp, but doesn't provide the full "story" or "feel" of Common Lisp, and I want to offer to HN my own perspective. Disclaimer #1: I've been working professionally as a Common Lisp programmer---not as a contractor!---for the past decade. I have a vested interest in the language and hiring for it. Disclaimer #2: I am going to ignore commercial implementations of Lisp here, which provide very useful and advanced features, like GUI development, a user-friendly IDE, paid support, etc. [1,2] So let's get started. Common Lisp's best feature is that it allows you to be insanely productive at the "raw programmer" level. You can write, edit, and debug code very quickly and incrementally, and end up with safe & performant code. There's a price to pay: currently the best-in-class experience is still Emacs and SLIME (which come nicely packaged here [3]). As an Emacs fan, that's the best news, but to my fellow PyCharm/VSCode/vim users, it's terrible and alienating news. My colleagues who aren't Emacs users managed to learn just enough Emacs to be productive in a week, but they still frequently fired up their editor of choice in times of need. It really is worth underscoring that the Emacs+SLIME experience truly fits Common Lisp development like a glove, and the experience, in my opinion, is better than almost every mainstream editor environment out there. Common Lisp's worst feature is that it feels like…

> I do subscribe to namespaces, since it allows global referencing of names I have been forced to use XML one way or another for a variety of uses (mostly integration, not document storage - but still), and have not ONCE had a use for namespaces or multiple DTDs in a single document. I suspect no one has statistics, but I wouldn't be surprised if this is true for 99.9% of {users,documents,systems} - which, if true, means that 1/1000 burdens the rest needlessly. But of course, this is mere speculation. > I also do subscribe to formal grammars, mature standards, and good documentation. XML is enticing by appearing to have those, but it actually doesn't, as Naggum articulated in[0]. XML schemas can describe a superficial structure, but not anything non-trivial and definitely not any semantics. Naggum is entertaining though he holds nothing back, see e.g. [1]. > It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten. The problem with XML is that, like lawyers, 95% of the population gives an undeserved bad reputation to all the rest. XML did have some good ideas, but they are almost nowhere to be find in practice. > This allows us to connect, say, 'com.facebook:Person' with 'com.google:Person' with a global equivalence relation. It allows us to specify bridges between standards. No it doesn't, unless they are semantically equivalent - which they never are. They might be superficially similar, with some translation…

Ah a Naggum re-discovery. See a yearly index here: https://www.xach.com/naggum/articles/ I went through the whole thing a few years ago, there are some gems hidden in there.

This reminded me of this old post from the late Erik Naggum on comp.lang.lisp: https://www.xach.com/naggum/articles/[email protected]…

Rather than rehash the ancient argument once again, I defer to this post: https://www.xach.com/naggum/articles/[email protected] (KMP was on both Common Lisp and Scheme standard committees; Erik Naggum was an eloquent, if controversial, Lisp expert)

It was named after the Pulp Fiction character. https://www.xach.com/gg/1997/1/profile/1/

There is a comp.lang.lisp archive published in 2009. > In 2009, Ron Garret published a 700MB archive file of all of comp.lang.lisp https://www.xach.com/naggum/articles/notes.html

You assumption "no one uses anymore" is glaringly wrong in this case. Those archives are full of useful and informative information. Not everthing changes fast. Common Lisp has been around for 30 years basically unchanged. The discussions back there can be truly informative for today. It does take time to wade thought it, but people have been collecting (via the google archive, when it existed, sigh) curated lists. https://www.xach.com/naggum/articles/ https://www.xach.com/rpw3/articles/

was he bootstraping a preliminary version of Erik Naggum? https://www.xach.com/naggum/articles/ (just joking)

You are correct: https://www.xach.com/gg/1997/1/profile/1/ Gimp Gazette 1 January 1997 "At the time, Pulp Fiction was the hot movie and a single word popped into my mind while we were tossing out name ideas. It only took a few more minutes to determine what the 'G' stood for."

http://xach.com/naggum/articles/ and http://xach.com/rpw3/articles/, for people interested in Lisp.

Naggum on UIs: "this is my _workbench_, dammit, it's not a pretty box to impress people with graphics and sounds. when I work at this system up to 12 hours a day, I'm profoundly uninterested in what user interface a novice user would prefer." Full post: http://www.xach.com/naggum/articles/[email protected]

For anyone not able to quickly locate the above mentioned items:- PCL: (Practical Common Lisp): http://www.gigamonkeys.com/book/ (chapters 16 & 17) Keene: (Object-Oriented Programming in COMMON LISP: A Programmer's Guide to CLOS): http://www.amazon.com/Object-Oriented-Programming-COMMON-LISP-Programm… Warp Speed intro: http://xach.com/lisp/jrm-clos-guide.html

...Click a button, or invoke a command and an empty, unremarkable rectangle appears. Little you know that it is a relic from an age long past... Emacs to me, first and foremost, is a doorway to another dimension, a place you can escape to from the absolute drudgery of the contemporary software development. ...A relic, yes, but it seems as alive as ever, a dark block inside it, blinking, like a pulse on a medical instrument... It is also a glimpse into what professional tools might be like, if they were not so obsessed about beginner users. [1] ...You wonder what the hell you should do with it... [1] I think Erik Naggum kind of nailed it in http://www.xach.com/naggum/articles/[email protected]

Python is strongly typed with one type This article about CL but it's applicable to Python as well: http://xach.com/naggum/articles/[email protected]

In short Common Lisp has two namespaces, one for functions and macros and a second for variable names - Scheme has one namespace. So you have fewer conflicts in naming in Common Lisp. In Scheme there is a lot of concern about hygienic macros that don't mess up the namespace. For more on that here is an inflammatory but well thought out exposition. http://www.xach.com/naggum/articles/[email protected] The book Let Over Lambda lays it out really well as well.

For more Naggum diatribes, visit http://www.xach.com/naggum/articles/.

This article reminded me of something I read about the Unix model vs the lisp model. I managed to track it down, it's a comp.lang.lisp posting by Erik Naggum. http://www.xach.com/naggum/articles/[email protected] The interesting part is the 3rd paragraph of the answer.

A nice addition to my slime/Emacs environment (which is really a rediscovery for me after almost 10 years in IDEs like Eclipse) was iimage[1]. It converts image file name in the REPL to inline images, makes it very easy to prototype functions that create some graphics. E.g. I use vecto[2] (also written by Zach!) to produce a disk usage visualization and it shows up directly below the function call in Emacs :D [1] http://www.netlaputa.ne.jp/~kose/Emacs/iimage.html [2] http://www.xach.com/lisp/vecto/ or (ql:quickload 'vecto)