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

211–220 of 271 posts

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

#211

Post by baggers »

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?

There are some other practical answers here so I'll take a different angle.

Fun! CL is a language to play in, after a day of wrangling Java & ObjC issues I love settling down to just play in an environment that lets blast some code out and play with ideas. Of course this applies to other languages too and this is dependent on your interests, so the case I want to put out there is:

Even if a language isn't suitable for your current business needs, see if it gives you joy. Languages have trades offs to meet their goals, evaluate languages for pleasure too.

Also come visit #lispgames on freenode sometime..most of us are procrastinating making engines but it's always nice to have new folks around.

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

#212

Post by baggers »

throwaway7645 wrote: post #79

"Dear windows user, tell us how this is done for SBCL" Watch YouTube video from Baggers. It's a lot more complicated than your average windows user will want to go through. Than you have to setup EMACS, quicklisp...etc. I never really new what quicklisp was doing and it made me nervous (I trust VS nuget).

The video in question: https://www.youtube.com/watch?v=VnWVu8VVDbI&t=744s

As aidenn0 mentioned portacle will hopefully be a good option for some when finished as it gives you a complete environment in one shot.

For installing CL I may update my video to use Roswell at some point, I've been having good success with it when using TravisCI.

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

#213

Post by hydandata »

pnathan wrote: post #49

Hi, HN! I made this! Ask me any questions you like. I'll try to respond as the workday progresses and I wait for deploys to complete! paul@nathan.house if you want to email me instead. (or @p_nathan on Twitter, if that's your thing).

You might want to mention https://github.com/fare/asdf/tree/master/uiop which is part of ASDF and bundled by default with most implementations.

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

#214

Post by Johnny_Brahms »

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 implementation are you using? I had the pleasureof using AllegroCL at a gig I did recently. The environment has a bit of a learning curve, but once everything clicks it is like heroin.

I ended that job a couple of months ago, but I still have wet dreams about it.

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

#215

Post by cdegroot »

Guthur wrote: post #120
shady-lady wrote: post #96

Earlier quoted context omitted.

Curious over why CL vs Clojure? Any comments.

I have used both in production setting and can say that the tooling for most CL implementations is just plain light years ahead of Clojure, and there is no sign of it really improving. For Clojure the interactive debugging experience is just plain dreadful and for a dynamic language this is pants on head crazy imo. For me a dynamic language has to have a good interactive debugging experience because you have foregone…

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 the thing that Smalltalkers always bring up and Lispers less so is also that your program and your IDE are basically indistinguishable, which is quite powerful because it makes it trivial to adapt your IDE to your project as you go. In the Lisp environments I've tried - latest being Emacs+SBLC - the split between editor and REPL seems unnatural to me, more so because in the standard case you work with two different dialects of the language. It seems that only ACL and LW have more unification.

Am I wrong and are the $$$$ versions not better in that respect and should I just drop my Smalltalk habits/arguments when learning CL?

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

#216

Post by cdegroot »

sheepmullet wrote: post #205
shady-lady wrote: post #96

Earlier quoted context omitted.

Curious over why CL vs Clojure? Any comments.

Clojure makes certain language sacrifices to ensure great integration with its host platforms. Easy access to the tens of thousands of person years worth of effort put into the Java/JavaScript ecosystems in return for dealing with a bit of ugliness is a win in my books.

It's a loss in my books. I like Clojure but pretty much the only thing that's been putting me off is how the JVM "shines" through in lots of aspects.

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

#217

Post by Zak »

pekk wrote: post #114
Zak wrote: post #75

Earlier quoted context omitted.

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.

Pascal has null. Does that mean it is dynamically typed?

It means every type in Pascal is actually a union of itself and null.

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

#218

Post by Zak »

lispm wrote: post #168
Zak wrote: post #65

Earlier quoted context omitted.

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.

Why would arguments in Lisp (= "list processor") form a vector? Is it so that the syntax of vectors can be used? Then it has technical consequences. Is it because of technical issues (arguments are vectors internally) and thus it can be exposed in the syntax, too? Or both?

I think the motivation for making the sequence of arguments in function/macro definitions vectors instead of lists was primarily syntactic - to make them look different from the body. They're definitely vectors internally though.

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

#219

Post by l04m33 »

pnathan wrote: post #172
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. ```

Thank you.

A new user introducing his own work in the first comment did seem suspicious, but I tried to make it relevant, and didn't mean to spam around.

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

#220

Post by lispm »

cdegroot wrote: post #215
Guthur wrote: post #120

Earlier quoted context omitted.

I have used both in production setting and can say that the tooling for most CL implementations is just plain light years ahead of Clojure, and there is no sign of it really improving. For Clojure the interactive debugging experience is just plain dreadful and for a dynamic language this is pants on head crazy imo. For me a dynamic language has to have a good interactive debugging experience because you have foregone…

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, ... there is also the McCLIM project where some ideas from the Symbolics GUI are used.

There are also countless other implementations from the past, which are now mostly forgotten, which had an integrated IDE (Golden Common Lisp for Windows, Corman Lisp for Windows, Macintosh Common Lisp, Medley, Open Genera for X11...),

Post reply on HN