How to write Common Lisp in 2017 – an initiation manual • Hacker News Board

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

#221

Post by peatmoss » Wed, Mar 29, 2017, 1:52 PM UTC

edem wrote: post #110

How does Common Lisp compares to Racket nowadays? I've seen a lot of activity but I can't decide which one to try out. I only have time for one of them ATM.

My personal, subjective, feeling is that the Racket offers an easier entry path (docs, libraries and library discovery, relative non-cruftiness, package management via raco, IDE, etc.). I also like that Racket is a little more biased toward FP than CL. I'm told the macro system is ahead of CL's, though I can't say I deeply grok macros.

The Racket community always feels friendly and welcoming to beginners, which is something the CL community hasn't always been.

I do like that CL has a standard with multiple implementations. That said, the standard feels old, and you can quickly run into libraries that were built with less-than-universal compatibility. Things like tail recursion in CL exist commonly in implementations, but not in the spec.

I've tried to carve out a bit of hobby time for lisps over the past few years. I started with CL and fought with the tooling and I could see the power, but I never felt great about my abilities with it. I tried Clojure and periodically use it as a stand-in for Java, and in that sense it is good. But these days, I've been playing in Racket, and it feels like the lisp I wish I'd started with.

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

#222

Post by peatmoss » Wed, Mar 29, 2017, 1:57 PM UTC

peatmoss wrote: post #221

edem wrote: post #110

How does Common Lisp compares to Racket nowadays? I've seen a lot of activity but I can't decide which one to try out. I only have time for one of them ATM.

My personal, subjective, feeling is that the Racket offers an easier entry path (docs, libraries and library discovery, relative non-cruftiness, package management via raco, IDE, etc.). I also like that Racket is a little more biased toward FP than CL. I'm told the macro system is ahead of CL's, though I can't say I deeply grok macros. The Racket community always feels friendly and welcoming to beginners, which is so…

One other item: the "enlightenment factor"—I'm really far from enlightenment, but I can see the crazy stuff people are doing in Racket with related, compatible languages, like Typed Racket and have a deep suspicion that Racket might carry me further on the path of enlightenment. That's down-the-road stuff for me though. Right now I'm enjoying small-time Racketeering.

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

#223

Post by peatmoss » Wed, Mar 29, 2017, 2:01 PM UTC

slmyers wrote: post #186

spdegabrielle wrote: post #130

Earlier quoted context omitted.

1. Racket is a multi-paradigm programming language. It has Java-style class/object system, a CLOS-like object system(swindle) and a prototype object system (like self and JavaScript). 2. The macro system is arguably the most sophisticated available. 3. Functionsl programming! including '(purely)Functional Data Structures'. 4. Parallelism (futures) 5. concurrency 6. Contracts 7. Typed Racket 8. Pattern matching 9. Mod…

> 17.an amazing IDE - it has a tool to debug macros! This may be true for an experienced user, but I've mainly used VS Code/Atom/Sublime etc, and I did not enjoy DrRacket -- I'm assuming that's what you're talking about. Some of the dropdown menus didn't render for me, and while this may sound stupid, I had the damnedest time figuring out that half my screen was a REPL and the other half a file.

How long ago did you try it / what platform are you running on? It was a few years ago now, but they rewrote the GUI libs to be native rather than whatever x-platform lib they used. DrRacket seemed to get... better then.

I mostly use emacs, but was playing with paredit for DrRacket with emacs keybindings the other day and decided that I could get to like some of the other creature comforts of DrRacket.

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

#224

Post by krylon » Wed, Mar 29, 2017, 2:03 PM UTC

killin_dan wrote: post #151

The biggest problem with lisp adoption imo is that the first step of every path begins with emacs. Emacs needs to die for lisp to flourish in a more modern editor. Light Table was a good start, but we need some power behind similar projects. I always thought guilemacs was the obvious successor, but it still hasn't happened.

Lisp and Emacs have decades of shared history, it's unlikely someone will really break this bond.

It would be nice to have alternatives, of course, but there is a reason certain people like emacs. (To be fair, I was an emacs user before I came across Lisp, but I can imagine how annoying/intimidating/frustrating it can be to somebody who has never used emacs before.)

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

#225

Post by peatmoss » Wed, Mar 29, 2017, 2:04 PM UTC

killin_dan wrote: post #151

The biggest problem with lisp adoption imo is that the first step of every path begins with emacs. Emacs needs to die for lisp to flourish in a more modern editor. Light Table was a good start, but we need some power behind similar projects. I always thought guilemacs was the obvious successor, but it still hasn't happened.

Since you mentioned Light Table, I'm going to guess that you're open to other lisps. I think this is one thing that the Racket folks get right. My wife's first foray into programming was a coursera course starting with a simplified variant of Racket, and the dev environment could not have been less of an issue.

EDIT: Also, emacs doesn't have to die. I love emacs! But DrRacket is a nice alternative for beginners (and I'm told) advanced users alike.

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

#226

Post by wruza » Wed, Mar 29, 2017, 2:13 PM UTC

ue_ wrote: post #81

pnathan wrote: post #51

Earlier quoted context omitted.

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…

The Common Lisp library ecosystem isn't as polished as it is in Python from what I know. Nor is the documentation for many libraries up to scratch, even the stellar ones. Some libraries merely document the functions provided and don't go into how to use the library. Even stellar libraries such as Hunchentoot do this, which I find rather annoying after using Python libraries which seem to make it an important point to…

I'm not an experienced web/http developer, but it [1] seems pretty understandable and even contains "Your own webserver (the easy teen-age New York version)" section for those who don't care, give them teh routez guys. define-easy-handler serves exactly that purpose.

From what I'm able to recall from my childhood, all docs were like that.

  [1] http://weitz.de/hunchentoot/

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

#227

Post by aidenn0 » Wed, Mar 29, 2017, 2:27 PM UTC

kahrkunne wrote: post #91

na85 wrote: post #31

If emacs is an obstacle to Common Lisp in 2017, maybe what's needed is a Lisp-interaction plugin for vi(m) (or whatever it is that vim uses in lieu of emacs modes). I don't get the hype for modal editing but you can't argue with the data clearly showing emacs users are in the minority.

Honestly I don't think Emacs is an obstacle to people who use Vim. It's an obstacle to people who use IDEs

IMO, It's an obstacle only to people who don't use IDEs.

Someone who uses e.g. visual studio for C++ isn't going to balk at the suggestion of installing IntelliJ for Java, and I doubt that they would balk at the suggestion of installing SLIME for lisp.

In my experience it's people who live in their editor (sublime, vim, &c.) that balk at the idea of installing an IDE as the first step for using a new language.

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

#228

Post by aidenn0 » Wed, Mar 29, 2017, 2:36 PM UTC

tarrsalah wrote: post #192

A newbie question please, How to deploy CL on production? I mean for long running programs.

There are a few ways of doing it all with different tradeoffs:

If very quick startup times are a necessity, then you just build a standalone image. This is very much like deploying a program in e.g. C. You build it with asdf, and then install it (and any dynamic libraries) into your deploy environment.

For "long running" programs, this may not be as necessary, and since the lisp runtime includes a full lisp compiler, it's not uncommon to just have a script that launches your lisp executable, uses ASDF to load the system, and calls the entry point.

For either one, it can also be useful to expose a swank server, though that does have security implications (anybody who can connect to the swank server (either localhost or unix domain sockets) can run arbitrary code).

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

#229

Post by aidenn0 » Wed, Mar 29, 2017, 2:44 PM UTC

s_kilk wrote: post #189

aidenn0 wrote: post #73

Earlier quoted context omitted.

It comes up in practice but is easilly avoided with the mapping of: null -> :null [] -> #() and false -> nil Mapping arrays to lists instead of arrays seems wrong to me, but is what most json libraries do by default. Fortunately most of them allow you to change that.

Would that mean I'd need to carry the `:null` symbol all throughout the codebase, wherever that data-structure might be accessed?

I'm not sure I understand the question. If you need to check if a value is null, you compare it with :null. It does mean that values you are going to serialize out to JSON should use :null rather than the more lispy nil, but JSON interfaces where you are required to send null values are quite rare (in fact I don't recall ever encountering one), so it hasn't been a problem for me in practice.

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

#230

Post by jerf » Wed, Mar 29, 2017, 2:51 PM UTC

Zak wrote: post #75

jerf wrote: post #34

Earlier quoted context omitted.

Most of the traditional definitions of "memory safety" are not violated by having null pointers, as long as they just crash when used incorrectly. nils in Go don't let you start accessing things you shouldn't or anything. Golang is memory safe by most definitions. (Possibly not by a definition that includes concurrent memory safety. I expect in 20 or 30 years the term "memory safe" will indeed involve that. But at th…

I'd put that one under type safety, and it definitely seems bizarre to me to make a new language that claims to have strong, static typing and allow arbitrary types, or pointers to arbitrary types to be null.

Go's nil is statically-typed. The nil keyword is polymorphic (as numbers in the source code are) but individual nils that occur at runtime in Go are actually typed. You can actually put methods on them and they execute just fine:

     type S struct{}

     func (s *S) Test() {
         if s == nil {
             fmt.Println("Nil pointer")
         } else {
             fmt.Println("Not nil pointer")
         }
     }

     func main () {
         var p *S
         p.Test()
     }

That will print "Nil pointer", not crash.

While I'm actually still in agreement that I don't love a language with nil pointers, it is less bad in Go because they are less pointy and stabby. It's not like C where they are automatically a crashing offense; they are valid values treated in sensible ways in a lot more places than in C, because in Go they still have their type associated with them. But I'd still like to be able to declare a non-nillable pointer type.

Please do note carefully the difference between less bad and not bad.