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

171–180 of 271 posts

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

#171

Post by pnathan »

brudgers wrote: post #83
pnathan wrote: post #55

Earlier quoted context omitted.

Hmmm. I tried to convey the idea, without getting too bogged down in the details that don't per se matter on Day 1. I would be interested in any PRs you have to clarify the matter adequately for people just starting out.

A few remarks: 0. It's a hard problem. I have a deep respect for your trying to tackle it. 1. The hard part is that it all matters on day one and everyone will get a lot of stuff wrong for a long while and some stuff wrong always when attempting non-trivial projects. This is the rule whether it's Python or Common Lisp or Racket. 2. I'm a fan of polyglotting languages in general and Lisp's in particular. For a person…

The niche of "welcome to Lisp, here's how to code" has been super well filled over the years. And regularly people write sort of intros to SBCL, CCL, etc. articulate-lisp isn't intended to do that - there are a few notes in that regard, just to whet your thoughts - and because I was bored - but it's not a thing there really.

But what is typically lacking is how you go from just a Lisp environment to a development environment that lets you operate at a professional level. Articulate-lisp is intended to deliver the thumbnail of how to get that put together, along with assorted references to further study.

At the time I created it, there was nothing really suitable for pro development out there. I guess roswell and portacle are things now.

Training wheels aren't really my bag of things. I'm notorious for preferring to read the O.G. paper on subjects rather than work through tutorials and simplified whatsits. But giving all the data at once doesn't provide the map of the territory that newbies crave.

There's no Royal Road to Lisp... or geometry. But a map to get you to where you're going does exist for geometry, and Lisp, I think deserves one too.

If that-all makes sense.

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

#172

Post by pnathan »

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.

Quoting this dead (and useful) comment for others who don't browse showdead:

```

l04m33 3 hours ago [dead] [-]

I wrote a new CL plugin for Vim, which only depends on +channel and supports most SLIME features: https://github.com/l04m33/vlime It's quite new, and I'd be grateful if you could try it out and provide some feedback.

```

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

#173

Post by kakapupu »

0xcde4c3db wrote: post #145
shady-lady wrote: post #96

Earlier quoted context omitted.

Curious over why CL vs Clojure? Any comments.

Not speaking for hydandata, a few key points of CL as opposed to Clojure (which might be advantages or disadvantages depending on context and preference) include: - Defined by a standard (the text of the standard is available for free online as the Common Lisp HyperSpec [1]), not by a reference implementation led by a BDFL - Multiple mature implementations, both free and proprietary - Wholeheartedly multi-paradigm; h…

> Defined by a standard

How does this help, compared to Clojure?

> Multiple mature implementations

Why wouldn't one free mature implementation be good enough?

> Wholeheartedly multi-paradigm

Exactly like Clojure.

> "Lisp-2" rather than "Lisp-1"

I can't remember which one Clojure is :) But I haven't had any problems with namespaces and the like.

> Designed for implementation in a wide variety of environments

So is Clojure, right? There's the CLR version, and ClojureScript too.

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

#174

Post by int_19h »

lispm wrote: post #169
int_19h wrote: post #150

Earlier quoted context omitted.

Arrays are functions, by definition. They relate inputs to outputs.

That does not mean I want them in a programming language to be functions.

I guess I just don't see a disadvantage. An array is a pure function, no side effects, so it should always be safe to treat it as one.

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

#175

Post by [deleted] »

PuercoPop wrote: post #162
Guthur wrote: post #115

Earlier quoted context omitted.

It baffles me that this notion of Lisp as an interpreted language still persists. Common Lisp is a compiled language for all non toy implementations, and in general Lisps have had compilers for decades.

It baffles me that people refer to languages as interpreted or compiled. That is a property of the implementation of the not the language.

[deleted]

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

#176

Post by lispm »

int_19h wrote: post #174
lispm wrote: post #169

Earlier quoted context omitted.

That does not mean I want them in a programming language to be functions.

I guess I just don't see a disadvantage. An array is a pure function, no side effects, so it should always be safe to treat it as one.

One disadvantage: you can't inline the code for such a vector reference, unless the compiler knows at compile time that this is a vector reference.

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

#177

Post by jabl »

pnathan wrote: post #136
ue_ wrote: post #81

Earlier quoted context omitted.

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…

The CL community tends to expect you to read the source. You're not just a user , you're a programmer too - and quite possibly of the library you want to use. It's an interesting dynamic, very alien to modern computing modalities.

Sometimes I get the feeling that the lack of CL libraries is somewhat self-imposed. "We don't need no stinking libraries. Since CL is so AWESOME, a competent CL programmer can reimplement whatever he needs in a fraction of the time that programmers using a lesser language would need even with the help of ready-made libraries". See "smug Lisp weenie".

Not saying that the above is actually factually true; certainly quicklisp has done a lot to make 3rd party libraries a lot more approachable.

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

#178

Post by phoe-krk »

znpy wrote: post #46

Some notes based on my (brief) experience toying with Common Lisp: * Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem. * The relation between the various native data-types were quite unclear to me. * dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got aba…

> * The relation between the various native data-types were quite unclear to me.

http://sellout.github.io/media/CL-type-hierarchy.png

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

#179

Post by lispm »

kakapupu wrote: post #173
0xcde4c3db wrote: post #145

Earlier quoted context omitted.

Not speaking for hydandata, a few key points of CL as opposed to Clojure (which might be advantages or disadvantages depending on context and preference) include: - Defined by a standard (the text of the standard is available for free online as the Common Lisp HyperSpec [1]), not by a reference implementation led by a BDFL - Multiple mature implementations, both free and proprietary - Wholeheartedly multi-paradigm; h…

> Defined by a standard How does this help, compared to Clojure? > Multiple mature implementations Why wouldn't one free mature implementation be good enough? > Wholeheartedly multi-paradigm Exactly like Clojure. > "Lisp-2" rather than "Lisp-1" I can't remember which one Clojure is :) But I haven't had any problems with namespaces and the like. > Designed for implementation in a wide variety of environments So is Clo…

Clojure variants are incompatible in various basic ways, since they use the host language for various things. The underlying platform also restricts what the implementation provides. No TCO in JVM -> no TCO in Clojure. Numbers are internally floats in Javascript -> Numbers are internally floats in ClojureScript and use Javascript semantics, not Clojure-Semantics.

Clojure:

  Clojure 1.8.0
  user=> (/ 3 4)
  3/4
ClojureScript

  cljs.user=> (/ 3 4)
  0.75
Looks like these are different languages...

Common Lisp implementations OTOH implement most of the standard. There is also more choice in implementations:

* native implementations AND hosted implementations

* actual Lisp interpreters or a mix of interpreters and compilers, interactive compilers, batch compiler

* compilers written in Lisp itself with good error messages, forms of compile-time type checking/inference, and advanced error handling (like SBCL, CMUCL)

* compilation to C, full embedding into C programs (ECL and others)

* full embedding in C++ (CLASP)

* compilation to shared libraries, embeddable into other applications

* whole program compilers for delivery of compact applications (like mocl)

The main Clojure compiler is written in Java and it shows...

https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

If one targets a certain host environment (JVM, Javascript, ...) then this range of options and choice might not matter, even hinder - besides getting a poorer version of interactivity.

If we see a Lisp as a language on its own, then it matters a lot.

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

#180

Post by 59nadir »

ethagnawl wrote: post #159
kazinator wrote: post #154

Earlier quoted context omitted.

Clojure is tied to the Java environment. Someone who has no use for or interest in that environment has no use for Clojure.

> Clojure is tied to the Java environment. I guess you're not familiar with ClojureScript and/or Clojure CLR?

That's sort of like the following:

- I don't want a door here.

- Ok, you don't like the wooden door here. You can have a plastic one or a steel door.

With CL you're not tied to _any_ platform.

Post reply on HN