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?
How to write Common Lisp in 2017 – an initiation manual
191–200 of 271 posts
Re: How to write Common Lisp in 2017 – an initiation manual
#192A newbie question please, How to deploy CL on production? I mean for long running programs.
Re: How to write Common Lisp in 2017 – an initiation manual
#193Earlier quoted context omitted.
REPL and interpretation are orthogonal concepts. SBCL (most common CL implementation) don't have interpreter at all. It complies into machine code before execution even in REPL.
Though, to be fair, a 'real' Lisp interpreter often provides more interactive features. The Lisp interpreter sees the code as Lisp data and interprets that. This enables a few things.
You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
Re: How to write Common Lisp in 2017 – an initiation manual
#194Can someone point me at an argument for why I'd want to write CL in 2017, given all the great alternatives available now?
I did a presentation about this some time ago where I try to explain how I develop Lisp software. Perhaps someone will find it informative:
https://engineers.sg/video/web-development-in-emacs-common-l...
Re: How to write Common Lisp in 2017 – an initiation manual
#195Earlier quoted context omitted.
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.
Every time I tried to get into CL, having to use Emacs/SLIME (which, let's face it, is the development environment for it for all practical purposes) has been a huge turn-off. So, yes. Please?
I had (and still have) a similar aversion to emacs, so I used to use Sublime with SublimeREPL plugin, which allowed me to run Common Lisp and Clojure (or any other language with a REPL) inside the editor. Pretty much a makeshift IDE, with an interface you're already used to. I've since moved on to VSCode, and I bet there must already be a way to replicate this in it, I just haven't had the need to work with Lisp since to explore this.
Re: How to write Common Lisp in 2017 – an initiation manual
#196Earlier quoted context omitted.
It's a seamless dynamic programming language, which can, with care, be given excellent performance and a high level of abstraction. In my opinion, it's miles better than the other dynamic languages out there, by nearly every factor. It rewards investment and development very well; it's a tool for mastery, not for quick and easy starting. If you're looking for statically typed languages, it's not going to win there. B…
Do you prefer it over Clojure? If yes why? I'm a bit versed with Clojure but sometimes I feel that it is not a true lisp.
> sometimes I feel that it is not a true lisp.
That feeling may be the result of some questionable syntactic design decisions in Clojure.
Hickey went over Lisp syntax and tried to remove parentheses wherever possible. (It was the hip thing, PG's Arc did it, too, which may be where Hickey got it from.) As a result, you get a sub-par editing experience —generic sexp-based structure editing doesn't get you as far as with a Lisp— and diminished readability once you get above three omitted pairs of parentheses in a row.
On the other hand, Clojure arbitrarily mandates a secondary kind of list literal in some places of the syntax, again making Clojure harder to write and edit. I don't even see a readability benefit, but of course YMMV.
TL;DR: Clojure syntax is a "complected" derivative of Lisp :-)
Re: How to write Common Lisp in 2017 – an initiation manual
#197Earlier quoted context omitted.
Though, to be fair, a 'real' Lisp interpreter often provides more interactive features. The Lisp interpreter sees the code as Lisp data and interprets that. This enables a few things.
You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
> You don't need an interpreter for that.
For what?
> You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
True, but that's not what a Lisp interpreter does and provides.
I was talking about the difference between an interpreter and a (possibly interactive) compiler. The interpreter works over source code as Lisp data. The compiler does not - it does not matter that the compiler compiles individual forms. At runtime the code is machine code. With an interpreter the code is Lisp data.
Think about it: What difference could that make, if the code gets actually executed by a real Lisp interpreter?
Re: How to write Common Lisp in 2017 – an initiation manual
#198Earlier quoted context omitted.
Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.
I don't use Go, but I thought that nulls in it were memory safe (i.e. they abort rather than corrupt); am I wrong? If I'm not wrong, this is a non-sequitor on a post about Common Lisp as Common Lisp is untyped, but (by default; some implementations allow you to disable safety) safe.
Technically Common Lisp is optionally typed. You can add static typing if you feel like it, and it can give you a significant performance boost when you do.
Fortunately, I don't have to bother with it most of the time since the amount of code that is time-critical enough for it to matter is very small.
Re: How to write Common Lisp in 2017 – an initiation manual
#199Earlier quoted context omitted.
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.
if a Common Lisp compiler sees a call to cl:aref then it can inline it, without using static flow analysis or similar...
Re: How to write Common Lisp in 2017 – an initiation manual
#200Earlier 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]