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

181–190 of 271 posts

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

#181

Post by kruhft »

hydandata wrote: post #148
lafytahoe wrote: post #139

Earlier quoted context omitted.

How do you sneak something like lisp in to work?

You build trust with stakeholders, usually by solving important problems until you reach a point at which having you solve a new problem is more important to them than what you solve it with. It helps if whatever tech you are introducing actually helps you in the task of solving more problems, increasing quality of solutions or reducing cost, in that particular order.

Good advice and similar to the strategy I use at work to use Common Lisp and Parenscript. They are yet to be completely accepted, but I'm working in it.

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

#182

Post by mathw »

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?

Last time I tried to use Clojure CLR, all the useful libraries were JVM-only because they called out to JVM libs underneath.

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

#183

Post by ane »

Guthur wrote: post #125
Royalaid wrote: post #123

Earlier quoted context omitted.

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.

I may be missing some massive leap but until it does this http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil...

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

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

#184

Post by mehaveaccount »

baldfat wrote: post #14
ConanRus wrote: post #2

Short answer: don't do that, use Clojure instead. It doesn't have any of listed problems.

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.

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

#185

Post by lispm »

ane wrote: post #183
Guthur wrote: post #125

Earlier quoted context omitted.

I may be missing some massive leap but until it does this http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil...

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.

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

#186

Post by slmyers »

spdegabrielle wrote: post #130
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.

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.

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

#187

Post by _pmf_ »

nerdponx wrote: post #124
aidenn0 wrote: post #89

Earlier quoted context omitted.

I don't know about emacs/slime, but it can manage local quicklisp and local implementations (and even have e.g. multiple sbcl versions installed simultaneously).

This sounds a lot like Pyenv and Virtualenv for Python. Neat!

I don't like Clojure (any more), but one nice thing about it is that is includes the Clojure implementation itself as regular versioned dependency on a project-by-project base (thanks to the transparent usage of Maven by the leiningen build tool). Once you tried this, everything else feels like a cludge; there's simply no reason the language version should be managed by some obscure mechanism instead of being a regular dependency!

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

#188

Post by adrianN »

ScottBurson wrote: post #103
brudgers wrote: post #38

Earlier quoted context omitted.

I mentioned elsewhere I'm learning Common Lisp. I'm also learning Python by translating some Common Lisp code into Python and part of that is to make sure I understand what the Common Lisp is doing. As an understatement, that's meant building some very unPythonic abstractions (yay, me). Anyway, I think there is a fundamental design difference between Common Lisp and other 'first class' programming languages: Common L…

I have a couple REPLs for specific projects that I routinely keep running for months at a time. The idea that user = programmer was part of the MIT AI Lab culture before there were Lisp Machines. For example, the top level of ITS, the PDP-10 OS they used, was the debugger. Imagine if the default Linux shell was GDB!

It's a little like that in TempleOS. The shell feeds into a HolyC compiler.

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

#189

Post by s_kilk »

aidenn0 wrote: post #73
s_kilk wrote: post #71

While people are directing their attention here: Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak). I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data. Can anyone comment on wh…

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?

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

#190

Post by int_19h »

lispm wrote: post #176
int_19h wrote: post #174

Earlier quoted context omitted.

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.

But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.
Post reply on HN