Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to write Common Lisp in 2017 – an initiation manual

articulate-lisp.com

Post reply on HN
Print view View original

61–70 of 271 posts

Re: How to write Common Lisp in 2017 – an initiation manual

#61

Post by lispm »

pnathan wrote: post #57
quickoats wrote: post #19

i do not know how to message the guy "Scott" author of page, so i am putting this here. in the "LispWorks CL" page, under "Implementations", the "Notes" section elicidates a mystery about the Personal Edition not recognizing the lisp init files. This is actually a limitation in LispWorks Personal Edition which is described on the link provided to retrieve said edition.

Ah, interesting! I don't remember reading that when I wrote it. I'll go back and correct it after my current project wraps up (but PRs are also accepted!).

The Personal Edition has several limitations:

does not load init files

supposed to be used with the IDE

IDE quits after some hours

Memory is limited

can't create applications

---

Actually the Personal Edition is mostly for people to play around a bit or students doing some homework.

Other than that the typical user will buy a version, which won't have the above limitations. Users also may also test a time-limited full version, before buying. People use either LispWorks or Allegro CL, then.

Re: How to write Common Lisp in 2017 – an initiation manual

#62

Post by pnathan »

lispm wrote: post #61
pnathan wrote: post #57

Earlier quoted context omitted.

Ah, interesting! I don't remember reading that when I wrote it. I'll go back and correct it after my current project wraps up (but PRs are also accepted!).

The Personal Edition has several limitations: does not load init files supposed to be used with the IDE IDE quits after some hours Memory is limited can't create applications --- Actually the Personal Edition is mostly for people to play around a bit or students doing some homework. Other than that the typical user will buy a version, which won't have the above limitations. Users also may also test a time-limited ful…

Yeah, I recall using it a bit more now.

The personal edition is really a trial edition, it's not a 'low budget low features' edition, which is what I was thinking when I originally was fooling with it back then.

(These days I use SBCL nearly exclusively for my CL implementation)

Re: How to write Common Lisp in 2017 – an initiation manual

#63

Post by brudgers »

_19qg wrote: post #47
brudgers wrote: post #38

Earlier quoted context omitted.

I mentioned elsewhere I'm learning Common Lisp. I'm also learning Python by translating some Common Lisp code into Python and part of that is to make sure I understand what the Common Lisp is doing. As an understatement, that's meant building some very unPythonic abstractions (yay, me). Anyway, I think there is a fundamental design difference between Common Lisp and other 'first class' programming languages: Common L…

> Lisp Machine (which was the future when Common Lisp was designed) Common Lisp was actually designed so that you don't need a Lisp Machine. The people working on it were from CMU (Unix workstations), Lucid (Unix workstations), Franz (Unix/Windows), Apple (Mac), Symbolics (Lispm, PC), Xerox (Lispm, Unix), and many others. Users used an editor-based IDE (like Franz ELI with GNU Emacs, ILISP with Gnu Emacs), a special…

Sorry for not being clear. I was not stating that Lisp Machines were an intended requirement, my intent was to point out that Lisp machines were the zeitgeist during the period when Common Lisp was incubated and developed and hypothesize that this is reflected in the design of the language.

As a point of contrast, Smalltalk was developed in part with the idea of Dynabooks in the hands of children. Hence its stereotypical use cases presume a substantial difference between the cognitive capabilities of the system's users and the cognitive capabilities of system's programmers.

Re: How to write Common Lisp in 2017 – an initiation manual

#64

Post by snowcrshd »

macco wrote: post #36

If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: https://atom.io/packages/atom-slime It doesn't replace emacs, but it works as a first Lisp ide.

Hmm, this just gave me an idea: Visual Studio Code Common Lisp plugin might also be a good way to expose the language to people unfamiliar to the language.

Re: How to write Common Lisp in 2017 – an initiation manual

#65

Post by Zak »

yarrel wrote: post #32
sigjuice wrote: post #8

Earlier quoted context omitted.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.

The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.

Re: How to write Common Lisp in 2017 – an initiation manual

#67

Post by lispm »

pnathan wrote: post #62
lispm wrote: post #61

Earlier quoted context omitted.

The Personal Edition has several limitations: does not load init files supposed to be used with the IDE IDE quits after some hours Memory is limited can't create applications --- Actually the Personal Edition is mostly for people to play around a bit or students doing some homework. Other than that the typical user will buy a version, which won't have the above limitations. Users also may also test a time-limited ful…

Yeah, I recall using it a bit more now. The personal edition is really a trial edition, it's not a 'low budget low features' edition, which is what I was thinking when I originally was fooling with it back then. (These days I use SBCL nearly exclusively for my CL implementation)

> 'low budget low features' edition

In some school/university course it would be like that. The students get a simple installer, get the IDE up and running after a few clicks and thus they don't have to learn GNU Emacs + installing Lisp infrastructure for some basic homework.

Re: How to write Common Lisp in 2017 – an initiation manual

#68

Post by azrazalea »

emidln wrote: post #52
SomeHacker44 wrote: post #24

Earlier quoted context omitted.

To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.

If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader. I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using d…

Virtually nothing requires reader macros. That doesn't mean they aren't useful.

Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.

Re: How to write Common Lisp in 2017 – an initiation manual

#69

Post by markc »

macco wrote: post #12
sigjuice wrote: post #8

Earlier quoted context omitted.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

Usually, people tend to see the following problems: * no native support, hosted language (js java) * unreadable (java) tracebacks * no tail call optimization These are not my problems with Clojure, but then things I often read. I am interested in Common Lisp because of the native support.

I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.

Re: How to write Common Lisp in 2017 – an initiation manual

#70

Post by _ph_ »

Scarblac wrote: post #10

I'm used to languages like Python, that have a number of files that are modules, and to start a program you run one of them as an entry point. C programs consist of a lot of files that are compiled and linked into a binary executable. Whenever I've tried to learn CL, I couldn't really wrap my head around what the eventual program would be. You build an in-memory state by adding things to it, later dump it to a binary…

You can build your Common Lisp programs from a set of files like any other programming language. "asdf" is the most common system which provides loading complex lisp system. I actually use a makefile to build my Common Lisp based executables from my set of files, no neeed to build up an in-memory state.

The difference with Common Lisp is, you are not limited to this build model, but while your whole code is loaded, you can keep redefining functions for development. This creates the minimal cycle of editing and testing any single function in your program. This is a big asset in development, but in no way means you have to build your systems that way. Actually the contrary, I can only recommend to restart your lisp image frequently to ensure the system loads and builds from file rather than depending on the image state.

Post reply on HN