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

101–110 of 271 posts

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

#101

Post by pekk »

reinhardt wrote: post #80
agentultra wrote: post #35

Earlier quoted context omitted.

I'll take a stab at this glib comment: 1. You've inherited an application written in Common Lisp 2. Common Lisp has features you find desirable that aren't available in another system 3. You like Common Lisp 4. Common Lisp helps you get the thing you're trying to do, done

You can replace "Common Lisp" with any other language and these points still stand (at least in a tautological, nonsensical way).

You're right that these arguments apply to many languages, but they're not tautological or nonsensical and the choice of Lisp (like many other choices) can be defended.

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

#102

Post by nameless912 »

netmask wrote: post #98
hydandata wrote: post #84

I started a big project at work using Common Lisp in 2017 and could not be happier. Sure, most nice features have trickled down to other languages, but they are rarely as nicely integrated. And Lisp still has many advantages that are not found elsewhere: Unmatched stability, on-demand performance, tunable compiler, CLOS, condition system, and Macros to name a few. It has its warts too but which language does not? I f…

which lisp interpreter did you use ?

Common Lisp would imply SBCL, that's my guess at least.

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

#103

Post by ScottBurson »

brudgers wrote: post #38
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…

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…

I have a couple REPLs for specific projects that I routinely keep running for months at a time.

The idea that user = programmer was part of the MIT AI Lab culture before there were Lisp Machines. For example, the top level of ITS, the PDP-10 OS they used, was the debugger. Imagine if the default Linux shell was GDB!

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

#105

Post by edem »

pnathan wrote: post #51
AlexCoventry wrote: post #27

Can someone point me at an argument for why I'd want to write CL in 2017, given all the great alternatives available now?

It's a seamless dynamic programming language, which can, with care, be given excellent performance and a high level of abstraction. In my opinion, it's miles better than the other dynamic languages out there, by nearly every factor. It rewards investment and development very well; it's a tool for mastery, not for quick and easy starting. If you're looking for statically typed languages, it's not going to win there. B…

Do you prefer it over Clojure? If yes why? I'm a bit versed with Clojure but sometimes I feel that it is not a true lisp.

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

#106

Post by fiddlerwoaroof »

s_kilk wrote: post #71

While people are directing their attention here: Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak). I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data. Can anyone comment on wh…

So, I really dislike truthiness and falsiness in other languages but somehow, in Lisp, it just seems to work. One thing that helps is that, in places where the distinction between null and false matters, other features of lisp help keep them distinct: so, for example, getting a value from a hash table returns nil if the value is not found and, consequently, you can't distinguish a missing key from a stored null. GETHASH solves this by returning multiple values: the first is the value stored (if there is one) while the second indicates whether or not the key was found in the hash table. Similarly, optional arguments [declared like (defun foo (&optional bar))] default to null but, if you want to no whether a value was actually passed, you can change the argument declaration to account for this: (defun foo (&optional (bar nil bar-p))) In this case, when bar isn't passed, bar-p will b nil but when bar is passed, it will be t.

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

#107

Post by Jach »

shady-lady wrote: post #96
hydandata wrote: post #84

I started a big project at work using Common Lisp in 2017 and could not be happier. Sure, most nice features have trickled down to other languages, but they are rarely as nicely integrated. And Lisp still has many advantages that are not found elsewhere: Unmatched stability, on-demand performance, tunable compiler, CLOS, condition system, and Macros to name a few. It has its warts too but which language does not? I f…

Curious over why CL vs Clojure? Any comments.

Why Clojure vs CL? The parent already mentioned some features that Clojure lacks, so if you don't care about features, what do you care about?

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

#108

Post by spraak »

Jach wrote: post #107
shady-lady wrote: post #96

Earlier quoted context omitted.

Curious over why CL vs Clojure? Any comments.

Why Clojure vs CL? The parent already mentioned some features that Clojure lacks, so if you don't care about features, what do you care about?

The child likely didn't know that

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

#109

Post by fiddlerwoaroof »

nameless912 wrote: post #102
netmask wrote: post #98

Earlier quoted context omitted.

which lisp interpreter did you use ?

Common Lisp would imply SBCL, that's my guess at least.

There are half a dozen CL implementations, for various purposes:

sbcl, ccl and open source implementations with built in compilers.

ecl is similar, but designed to be easily embeddable in C applications

clasp is a newer one that's built on top of llvm (still unstable, as far as I can tell, but actively developed)

abcl targets the jvm platform and, consequently, can gives you access to all the libraries in the Java ecosystem.

And then there are commercial implementations like LispWorks and Allegro that have their own benefits: Lispworks has, I here, a very nice cross-platform GUI library and, although I don't know much about it, I suspect Allegro has it's own perks.

And, because of the community's emphasis on avoiding implementation-specific behaviors, which implementation you choose isn't that big a deal: I regularly develop a project under multiple implementations, and seldom have major issues doing so.

Post reply on HN