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

201–210 of 271 posts

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

#201

Post by ane »

lispm wrote: post #185
ane wrote: post #183

Earlier quoted context omitted.

CIDER has had debugging abilities like this for a year, there's a sexp based interactive debugger that allows injection, evaluation, stepping etc. Here's a 39 second video about it https://www.youtube.com/watch?v=A3JAlWM8qRM

The debugger needs to 'instrument' the code with breakpoints...? That's something different. In a Lisp system I would have an arbitrary amount of code and can halt and inspect/debug any code without any prior need to 'instrument' code.

To debug a function, yes, you need to eval the form using instrumentation. Then the debugger starts when this form is evaluated. This is the the only major difference to what SLIME provides. Adding breakpoints is somewhat easier with cider, you don't need to call break but you can just add a breakpoint to any sexp by pressing b.

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

#202

Post by dtornabene »

juanre wrote: post #191

I wrote in Common Lisp the star map generation software at the core of my startup, http://greaterskies.com , and could not be happier. But now that it's getting off the ground I wonder whether it may adversely impact my chances of being acquired. Are there any known examples of recent CL-based startups?

I don't know about being acquired but I believe there is a canadian travel-oriented startup using CL for an algorhythmically important part of their stack. I forget what it was called.

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

#203

Post by zehemer »

Royalaid wrote: post #123
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…

Have you tried out recent versions of CIDER? I find it works good for that I need. But I have to say that the big problem I have is Emacs and its inability to handle long strings.

Toggling pretty printing via `cider-repl-toggle-pretty-printing` may provide a workaround there. Courtesy of: https://github.com/clojure-emacs/cider/issues/1115

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

#204

Post by lispm »

ane wrote: post #201
lispm wrote: post #185

Earlier quoted context omitted.

The debugger needs to 'instrument' the code with breakpoints...? That's something different. In a Lisp system I would have an arbitrary amount of code and can halt and inspect/debug any code without any prior need to 'instrument' code.

To debug a function, yes, you need to eval the form using instrumentation. Then the debugger starts when this form is evaluated. This is the the only major difference to what SLIME provides. Adding breakpoints is somewhat easier with cider, you don't need to call break but you can just add a breakpoint to any sexp by pressing b.

> Then the debugger starts when this form is evaluated.

You mean the stepper using break-instrumented code? That's just a part of what one would call 'debugger' in Lisp.

What CIDER calls 'debugger' would be mostly called 'stepper' in Lisp.

http://franz.com/products/allegro-common-lisp/stepper_dialog...

http://www.lispworks.com/documentation/lw70/IDE-M/html/ide-m...

> Adding breakpoints is somewhat easier with cider, you don't need to call break but you can just add a breakpoint to any sexp by pressing b.

LispWorks does that, too. Usually via a break icon in the window toolbar or the context menu.

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

#205

Post by sheepmullet »

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.

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.

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

#206

Post by TeMPOraL »

juanre wrote: post #191

I wrote in Common Lisp the star map generation software at the core of my startup, http://greaterskies.com , and could not be happier. But now that it's getting off the ground I wonder whether it may adversely impact my chances of being acquired. Are there any known examples of recent CL-based startups?

Not a startup per se, but Grammarly is a well-known company using Common Lisp for their core product.

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

#207

Post by baggers »

snowcrshd wrote: post #64
macco wrote: post #36

If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: https://atom.io/packages/atom-slime It doesn't replace emacs, but it works as a first Lisp ide.

Hmm, this just gave me an idea: Visual Studio Code Common Lisp plugin might also be a good way to expose the language to people unfamiliar to the language.

It would be a very good idea. Be sure to make it talk to swank (the server side of the current editor tooling) so you can benefit from all the work that has been done there

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

#208

Post by baggers »

pnathan wrote: post #56
macco wrote: post #36

If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: https://atom.io/packages/atom-slime It doesn't replace emacs, but it works as a first Lisp ide.

Really! Do you use it? Would you feel comfortable submitting a PR explaining how to set it up? I HATE recommending emacs as the IDE for Common Lisp if it's not something people are comfortable with already.

It's very promising but still very young. I manage to break it very quickly each time I have tried using it.

Eventually though this will be a huge boon.

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

#209

Post by macco »

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

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

#210

Post by baldfat »

mehaveaccount wrote: post #184
baldfat wrote: post #14

Earlier quoted context omitted.

I am sure there are plenty of people who have a preferred Lisp. It does drive me nuts how if there is a post on R the top comments are people touting Python as being the bigger player in statistics and data science (Which it isn't) or a ton of other languages. PS I perfer Racket :)

R is pretty pointless though. Unless you want to rewrite everything between prototyping in R and real deployment with a real language, you are better off writing in Python.

That right there is what I am talking about. I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years.

Why would you ever have to rewrite the code? Python isn't faster and has less function then R and if you want you can just drop a few lines of Python in a cell of a Notebook. I like Python and its a good choice but R is a great language that in fact that Python's pandas library is trying to make a R equivalent.

Post reply on HN