Common Lisp homepage • Hacker News Board

Re: Common Lisp homepage

#101

Post by klibertp » Thu, May 10, 2018, 2:55 PM UTC

mtreis86 wrote: post #63

FractalLP wrote: post #53

Earlier 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…

6 - what about https://common-lisp.net/project/bordeaux-threads/

lparallel[0] is a higher-level abstraction built on threads. I use it for spawning threads which execute OS commands and wait for the results, without blocking the main thread. Works very well.

And anyway, if you want concurrency and/or paralellism, just go for OTP (Erlang, Elixir, LFE).

[1] https://lparallel.org/overview/

Re: Common Lisp homepage

#102

Post by mathnode » Thu, May 10, 2018, 3:00 PM UTC

djhaskin987 wrote: post #75

Any good implementations if common lisp on Windows?

I use sbcl and chezscheme on windows 10.

My editor of choice is Sublime Text with the SublimeRepl and Parinfer plugins.

Re: Common Lisp homepage

#103

Post by vesak » Thu, May 10, 2018, 3:03 PM UTC

kamaal wrote: post #87

vesak wrote: post #84

Earlier quoted context omitted.

Pascal, perl, ASP, every ML, Fortran, Cobol, Eiffel, Modula, all "4GL" languages.

None of them have faded. Cobol? Seriously, there are probably more Cobol programmers than there are Python programmers. And C? Most of the world runs on C, and its irreplaceable language in a non desktop computer. And you will be surprised how much Perl code is written everyday. The root comment is talking about the fad of the year, the kind of a language web devs use as flavor of the year. The current ones are Javas…

Yeah, when I wrote the comment, I kinda guessed that people would point out the zombie-like state of living for these languages. That's only barely being alive, though, and very much faded.

(I did have C in there but edited it out. I don't think that's a dead language yet.)

Re: Common Lisp homepage

#104

Post by kbp » Thu, May 10, 2018, 3:06 PM UTC

stassats wrote: post #100

kbp wrote: post #94

Earlier quoted context omitted.

> 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.

> what implementation really does that with SAFETY being 3?

LispWorks:

    CL-USER 1 > (declaim (optimize safety))
    NIL
    
    CL-USER 2 > (defun f (x) (declare (fixnum x)) x)
    F
    
    CL-USER 3 > (f "foo")
    "foo"

Re: Common Lisp homepage

#105

Post by dragandj » Thu, May 10, 2018, 3:12 PM UTC

lenkite wrote: post #21

susam wrote: post #7

Lisp is quite popular at my current workplace. A few popular open source projects published by our organization have been written in Clojure (a dialect of Lisp that runs on JVM and CLR). A few domain specific languages used internally in our organization are also inspired by Lisp. On a more personal front, I find Lisp to be simple, elegant, and expressive. I use Common Lisp (SBCL) for personal use. Working with Lisp…

I liked clojure when I dived into it but lack of static typing is a pain especially once you have got used to the wonderful refactoring and code-intelligence abilities you get by adopting the tools of static typed programming languages like Java/Go/C#/F#. Also performance!

Clojure has Java's static typing and you can also typehint things explicitly.

Re: Common Lisp homepage

#106

Post by stassats » Thu, May 10, 2018, 3:16 PM UTC

kbp wrote: post #104

stassats wrote: post #100

Earlier quoted context omitted.

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.

> what implementation really does that with SAFETY being 3? LispWorks: CL-USER 1 > (declaim (optimize safety)) NIL CL-USER 2 > (defun f (x) (declare (fixnum x)) x) F CL-USER 3 > (f "foo") "foo"

It needs (optimize safety debug) and the function needs to be compiled (interpreted code doesn't perform any optimizations based on the types).

Re: Common Lisp homepage

#107

Post by YouAreGreat » Thu, May 10, 2018, 3:30 PM UTC

lispm wrote: post #95

YouAreGreat wrote: post #70

Earlier 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…

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. http://sbcl.org/manual/index.html#Handling-of-Types

Thanks. Seems my assessment and SBCL's self-description match perfectly, as they explicitly aim to "reward the use of type declarations throughout development" and exhort users to "always declare the types of function arguments and structure slots as precisely as possible".

They do want their users to use one of Common Lisp's least safe features pervasively.

If the point was to mine assertions for type information, they could have encouraged the use of assertions. But they don't. They encourage the use of declarations, which is entirely not the same thing, and it's a bad thing for the Common Lisp source code ecosystem, even if not for the SBCL ecosystem. Hurray for SBCL.

Re: Common Lisp homepage

#108

Post by kbp » Thu, May 10, 2018, 3:34 PM UTC

stassats wrote: post #106

kbp wrote: post #104

Earlier quoted context omitted.

> what implementation really does that with SAFETY being 3? LispWorks: CL-USER 1 > (declaim (optimize safety)) NIL CL-USER 2 > (defun f (x) (declare (fixnum x)) x) F CL-USER 3 > (f "foo") "foo"

It needs (optimize safety debug) and the function needs to be compiled (interpreted code doesn't perform any optimizations based on the types).

Sure, but the point is that that exact same code will throw a type error in SBCL. It at least complicates what you need to do before you can say "what implementation doesn't behave like that?".

Re: Common Lisp homepage

#109

Post by martinflack » Thu, May 10, 2018, 3:34 PM UTC

elbear wrote: post #19

I 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?

You might like to look at Shen: http://www.shenlanguage.org/

Re: Common Lisp homepage

#110

Post by drmeister » Thu, May 10, 2018, 3:34 PM UTC

oblio wrote: post #81

drmeister wrote: post #64

This 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…

> how I don't have to worry about it fading like the next programming fad. I'm not sure I understand this bit. What other programming language has "faded" and how has it "faded"? At least since the more mature age of software, which I'd say started around '95 or so (so 20+ years).

I say this with a perspective of watching it happen over forty years. I'll get all kinds of heck if I start saying this or that language has faded. But many languages have changed over time, sometimes in breaking ways, as their developers work to make them more expressive and add features. Code that is written one year often doesn't work a few years later - that's a kind of fading as specific reference implementations fade away and code written in them needs to be updated or it rots.

Common Lisp doesn't have this problem - and it has many features that other languages have added over time, often in less comprehensive ways. For example C++11 lambdas are not as expressive and powerful as Common Lisp first class functions, and I joke that C++ template programming is to Common Lisp macros what IRS tax forms are to poetry. Note: Clasp includes a lot of C++ template programming and C++ lambda code that I enjoyed writing and I am so grateful that C++11 added variadic templates. New language features can be added to Common Lisp by the programmer with macros, and for the really adventurous, they can be made efficient by augmenting the Common Lisp compiler. Common Lisp compilers are almost always written in Common Lisp and available and accessible. This is why Clasp uses a new and understandable Common Lisp compiler "Cleavir" (developed by Robert Strandh) and LLVM, which is a great C++ library for generating native code on a variety of processors. Cleavir will be an excellent platform for efficiently implementing new dynamic programming language features.