I highly recommend Eitaro Fukamachi's caveman2 for very quickly setting up a very fast lisp web server including very easy to configure ssl. Fukamachi's Dexador library is also fantastic for very quick and easy ssl http functionality. https://github.com/fukamachi/caveman https://github.com/fukamachi/dexador
Common Lisp homepage
91–100 of 313 posts
Re: Common Lisp homepage
#92Earlier quoted context omitted.
From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for…
Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to suck…
That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all.
And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type.
Spreading misinformation like this is what's poisoning the ecosystem.
Re: Common Lisp homepage
#93This is a very nice web site describing a programming language with unparalleled expressiveness, power and permanence. I am heavily invested in Common Lisp. We are developing a programming environment for designing new materials and molecules called Cando ( https://github.com/drmeister/cando ) using Common Lisp as a scripting language. Cando is running on Clasp ( https://github.com/clasp-developers/clasp ), a new Com…
Hi, great fan of your presentations on clasp. Have you had an opportunity to look at Julia? It seems that there is some overlap in what can be achieved - with some obvious differences: as I understand it you had a lot of c++ - that could probably (today) be linked from julia, but not "integrated", starting from a green field with Julia, ideally one could do most things in Julia - maybe with some help from rust. And J…
Thank you.
I did choose Common Lisp over Julia - I started learning Common Lisp in 2013 and Julia started becoming something around 2012.
I did so because of the permanence and the demonstrated expressiveness and power of Common Lisp. Common Lisp has been around for almost five times longer than Julia, and Common Lisp has demonstrated again and again that it is capable of solving hard, poorly understood, real world problems in a lot of domains.
Fun fact: Julia bootstraps off of an implementation of Lisp. Furthermore, most compiled languages are translated into an abstract syntax tree (AST) as part of compilation. Lisp S-expressions are a text based AST. So I can make the argument that Lisp is as close the "One True Programming Language" that we have. :-)
I'm doing chemistry - that's fundamental and timeless - I find it maps beautifully to a fundamental and timeless language like Lisp.
Re: Common Lisp homepage
#94Earlier quoted context omitted.
Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to suck…
That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all. And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type. Spreading misinformation like this is what's poisoning the ecosystem.
> And there is no undefined behavior at all.
Well, there is. Violating type declarations is UB in Common Lisp, the only thing the standard says about it is "the consequences are undefined". In SBCL, an error will be signalled, but there's no guarantees about what other compilers might do. This could show up if a Lisp programmer who primarily used SBCL was relying on the type system to do some of their input validation for them when portable code would have to actually check it (ie, in their head they might think their program will raise an error if you pass it garbage, when really it just invokes UB if you pass it garbage). I still don't think it's that big of an issue, and mentioning it alongside benchmarks certainly indicates some misunderstanding, but it's not completely baseless.
Re: Common Lisp homepage
#95Earlier quoted context omitted.
From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for…
Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to suck…
SBCL checks type declarations at compile time and at runtime.
The default fully safe code in SBCL is already fast enough for many cases.
You need to check the manual of SBCL sometime.
Re: Common Lisp homepage
#96(mapcar #'string-downcase (list "Hello" "world!")) This is a great example of why I don't want to use Common Lisp. Compare with Python: [word.lower() for word in ("Hello", "world!")] Beating Node and Ruby in terms of speed is also a big non-argument, with so many attractive programming languages to choose from that are both fast and good looking.
Can you elaborate on why?
I know both Python and Common Lisp, neither version looks any better than the other to me.
Also, as another commenter notes, the snippets are not actually good translations of each other. Your CL snippet would look like this in Python:
list(map(str.tolower, ("Hello", "world!")))
(loop for word in '("Hello" "world!") collect (string-downcase word))
Re: Common Lisp homepage
#97Earlier quoted context omitted.
I'd say several reasons: 1.) a lot of folks have trouble with the abstactness 2.) a lot of folks think C syntax is how all languages should be 3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new 4.) poor windows support for SBCL...it literally tells you it is experimental if I recall correctly. Set…
1: I really don't see how CL or Clojure are any more complicated than, say, Rust or C++. If anything, CL and Clojure are simpler, just different. 3: Most useful libraries are portable between different CL implementations. The choice is really "CL or Clojure or which Scheme implementation?" Not to discredit Picolisp or Shen, but those languages feel very much (esp. Shen) like a research language. Picolisp has more of…
>Lisp related books are among the best in CS. SICP, LoL, etc. are timeless.
Lisp books also tend to have the characteristic where you have to find the "right" compiler for the examples to work. I've yet to pick up a book where all the examples "just work".
Re: Common Lisp homepage
#98Earlier quoted context omitted.
That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all. And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type. Spreading misinformation like this is what's poisoning the ecosystem.
> And there is no undefined behavior at all. Well, there is. Violating type declarations is UB in Common Lisp, the only thing the standard says about it is "the consequences are undefined". In SBCL, an error will be signalled, but there's no guarantees about what other compilers might do. This could show up if a Lisp programmer who primarily used SBCL was relying on the type system to do some of their input validatio…
It's only undefined in the standard. Most implementations document their behavior somehow.
Generally I run my code with safety 3 and only selected portions might have unsafe code - but with args check before in surrounding code.
Re: Common Lisp homepage
#99I know the article is about Common Lisp, but I have a question about Racket, Typed Racket specifically. Can anyone say if types and Lisp play well together? Are there any success stories?
Types are supported since the 80ies, with (the) and optional declarations. Almost nobody uses them. Well, CL says: types are always carried around in every value, so we do have types, and we are always type-safe. Which is a proper point. Then SBCL has superior internal type support in its python compiler, leading to many optimizations. It creates specialized copies of typed methods, and has a nice optimizer framework…
In my experience Typed Racket programs are never slower than their dynamically typed Racket equivalents. Sometimes they are faster (such as when the program does a lot of numeric computation).
What _can_ be slower is a _mix_ of TR and R. Because TR protects the boundary between the two with runtime contracts. Because it wants safety/soundness.
I'm not any kind of gradual typing expert, but, it seems like you could calibrate speed vs. soundness for boundaries in different ways. TR has prioritized soundness but it seems like you prefer speed.
Re: Common Lisp homepage
#100Earlier quoted context omitted.
That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all. And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type. Spreading misinformation like this is what's poisoning the ecosystem.
> And there is no undefined behavior at all. Well, there is. Violating type declarations is UB in Common Lisp, the only thing the standard says about it is "the consequences are undefined". In SBCL, an error will be signalled, but there's no guarantees about what other compilers might do. This could show up if a Lisp programmer who primarily used SBCL was relying on the type system to do some of their input validatio…
That is theoretically true, but what implementation really does that with SAFETY being 3?
Claiming that SBCL following the standard is poisoning anything is completely baseless, though.