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

251–260 of 271 posts

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

#251

Post by db48x »

TeMPOraL wrote: post #50
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…

> 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. A friend of mine is working on that as we speak. The CLUS, or Common Lisp UltraSpec: https://phoe.tymoon.eu/clus/doku.php That said, CLHS isn't bad - it's lightweight, available off-line, and on-line you can pretty much always find what you're looking for by searching for…

Ah, this is something to follow. Sadly it doesn't seem to have a permuted symbol index, which is what I really love about the CLHS. Still, I suppose they have to start somewhere.

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

#252

Post by db48x »

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?

Symbols are interned, and become a simple integer comparison once compiled. It's no different than comparing against 0, except that :null will have some other non-zero value.

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

#253

Post by lispm »

int_19h wrote: post #249
lispm wrote: post #199

Earlier quoted context omitted.

if a Common Lisp compiler sees a call to cl:aref then it can inline it, without using static flow analysis or similar...

I was under the impression that CL compilers already had to do a lot of fairly complicated static analysis to achieve acceptable performance, because of dynamic typing.

Depends. Since the developer can use low-level functions and provide type declarations, a compiler can generate usefully fast code without too much work. More advanced compilers need less declarations, since they do some amount of type inference. One of the costs: the compiler then usually is quite a bit slower.

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

#254

Post by brudgers »

pnathan wrote: post #171
brudgers wrote: post #83

Earlier quoted context omitted.

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 env…

What you say makes sense to me.

I think a resource for "leveling up" is probably better if it is opinionated. I mean, there are reasons a person might not want to use Emacs for Common Lisp development (aside from using a product with a built in IDE), but there's no reason to handle edge cases which have little to do with "leveling up" on Common Lisp...there may be a SLIME mode for Atom, but someone who chooses it is swimming upstream in terms of Common Lisp.

The situation is similar in regard to Lisp installations. There are good reasons not to use SBCL, but they probably don't have that much to do with "leveling up" (again outside the commercial IDE world) and trying to cater to those non-leveling up reasons is a distraction.

To put it another way, a person who is just starting out is not in a position to make decisions based on experience. A year later, they may have the experience to make informed decisions because they have learned what matters and what does not.

I hopeful for Roswell and Portacle, but not terribly optimistic in ways that are similar to when I hear about a new Linux distro. The hard work is not the exciting honeymoon period. It's grinding out maintenance over the years without getting paid. It's designing good features for other people without getting paid. Most projects cannot do it.

Part of the problem is that leveling up on Common Lisp is mostly a matter of will to RTFM. Sure a site can have a great article explaining Common Lisp packages, but to understand packages, readers will need to understand symbols and so the options are:

1. Expect the reader to already understand symbols.

2. Describe all of Common Lisp.

3. Accept that the reader will still have a lot of work to do after reading the article.

1 and 3 collapse into similar requirements for an author. 2 works if the author writing a book and really knows their stuff.

Not sure how any of that is applicable here.

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

#255

Post by killin_dan »

peatmoss wrote: post #225
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…

Yes, but racket is a terrible language to work with. I've mentioned for years that drracket needs a general sexpr mode and integrated terminal for something like geiser. They don't listen.

I am working on a general purpose solution, but I'm just one person. And I don't leverage public dollars to write bad tools from the safety of university, so that slows it down a bit.

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

#256

Post by killin_dan »

macco wrote: post #209
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.

Use atom with slime: https://atom.io/packages/atom-slime

Atom is somehow even heavier than emacs.

Because EVERY editor should definitely include the bloat of a web browser.

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

#257

Post by peatmoss »

killin_dan wrote: post #255
peatmoss wrote: post #225

Earlier quoted context omitted.

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…

Yes, but racket is a terrible language to work with. I've mentioned for years that drracket needs a general sexpr mode and integrated terminal for something like geiser. They don't listen. I am working on a general purpose solution, but I'm just one person. And I don't leverage public dollars to write bad tools from the safety of university, so that slows it down a bit.

> racket is a terrible language to work with.

> ...

> I don't leverage public dollars to write bad tools

That's, like, your opinion, man!

Further, if your habit is to make feature requests in combination with this kind of subjective disparagement, I can see why the Racket community didn't jump to implement your request.

Lighten up. Everyone here is on the same team.

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

#258

Post by kahrkunne »

ruleabidinguser wrote: post #156
kahrkunne wrote: post #91

Earlier quoted context omitted.

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

I use(d) vim and see EMacs as annoying.

It might be annoying but it probably wouldn't be an "obstacle", especially considering things like evil-mode exist.

That's how it went for me, anyways. From vim user to trying Emacs because it has some feature that I need to becoming a full-time Emacs users with evil-mode

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

#259

Post by iheartmemcache »

lispm wrote: post #220
cdegroot wrote: post #215

Earlier quoted context omitted.

The JVM indeed quickly got me disinterested in Clojure. However, I have similar issues with other (free) Lisps, with probably only Emacs Lisp being the exception. As a Smalltalker ("the other heroin of the programming world") I'm used to a highly integrated and responsive development environment; from what I heard from other Lispers, the quick feedback and gradual building up of your program is a shared aspect, but t…

> also that your program and your IDE are basically indistinguishable Lisp provides that,too. But you can also deliver programs with the IDE and much of the development tools removed. Examples for integrated IDEs: Allegro CL on Windows/Unix+Gtk, Clozure CL (free) on Macs, LispWorks on Windows/Macs/Unix+GTK/Unix+Motif. There the IDE and the user code runs in one Lisp. Other examples: Lisp Machines, CMUCL on X11, ... t…

You should really write an analysis contrasting the functionality of these IDEs, especially those 'mostly forgotten' ones so they aren't lost into the abyss.

I've used Squeak Smalltalk and DrRacket in the past. As someone who finds slime/swank/sbcl in Emacs a pleasure, I can only imagine how great some of those other environments can be.

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

#260

Post by kunabi »

azrazalea wrote: post #235
kunabi wrote: post #117

I've been working on a CL project for a couple of years. Was my first big stab at using CL for something other than a toy. Sbcl is a nice choice, but far from the only option. It has many tradeoffs. CL is not without its frustrations. Documentation that has not aged well. A community that can be less than welcoming. (in contrast to say the Racket community) Inconsistencies, e.g. first, nth, elt, getf, aref... However…

This talks about GC settings that worked for them in SBCL for production, not sure if you already tried the same kind of stuff but may be an interesting read http://tech.grammarly.com/blog/posts/Running-Lisp-in-Product... . If you can make an easy to run example of the garbage collector not working correctly, the folks in #sbcl on freenode are very responsive and have commit access to fix it.

Good to hear someone had good interactions in #sbcl Still have a bitter taste from attempting to report the issue there.
Post reply on HN