[HN Gopher] Using SBCL Common Lisp as a Dynamic Library
       ___________________________________________________________________
        
       Using SBCL Common Lisp as a Dynamic Library
        
       Author : pcr910303
       Score  : 70 points
       Date   : 2022-04-16 18:30 UTC (4 hours ago)
        
 (HTM) web link (mstmetent.blogspot.com)
 (TXT) w3m dump (mstmetent.blogspot.com)
        
       | christophilus wrote:
       | I love lispy languages-- Clojure being the one I'm most familiar
       | with, but it's hard to give up static types.
       | 
       | Anyone here worked on a large lisp codebase? How big was it? How
       | big was the team? What's the secret sauce?
        
         | fiddlerwoaroof wrote:
         | One advantage of lisps is that you work at run time. So, you
         | can access runtime information in your editor, which makes up
         | for some of the limitations of dynamic types: static types
         | propagate information ahead of time that a Lisp can discover
         | through introspection.
        
         | bachmeier wrote:
         | I suppose it depends on what you mean by "static types" since
         | you can optionally specify types in Common Lisp. SBCL even does
         | precise type checking[1]:
         | 
         | "If a variable is declared to be (integer 3 17) then its value
         | must always be an integer between 3 and 17. If multiple type
         | declarations apply to a single variable, then all the
         | declarations must be correct; it is as though all the types
         | were intersected producing a single and type specifier."
         | 
         | [1] http://www.sbcl.org/manual/#Handling-of-Types
        
           | christophilus wrote:
           | Dang. I didn't know sbcl did this. I've never used it, but
           | now I want to try. Thanks!
        
           | maydup-nem wrote:
           | I would like to add that optimizations may also be performed
           | in addition to type-checking (type-checking, by the way,
           | depends on safety optimization level). What's also handy is
           | that you can specify the optimization levels (space, safety,
           | speed, debug) per function or per file (or in a `locally'
           | block).
           | 
           | Function return types may also be specified, with serapeum's
           | ->, it may be as simple as (-> f (fixnum fixnum) boolean) for
           | instance, right above the function.
           | 
           | Classes and structs let you specify types for slots.
           | 
           | Expressions may be typed with `the' special operator aka (the
           | fixnum (first list)).
           | 
           | PS CL has gradual typing.
        
           | bitwize wrote:
           | Type systems at least as rich as Hindley-Milner are pretty
           | much table stakes in 2022. Common Lisp's type system is not
           | as rich as Hindley-Milner. I believe it doesn't even support
           | user-defined parametric types (so it's kind of like pre-
           | generics Go in that regard). It lets you type function args,
           | but it doesn't incorporate the args' types into the function
           | type.
           | 
           | So no, Common Lisp's type system, even with static type
           | checking enabled, is not adequate for software engineering in
           | the present day. Coalton, however, solves many of these
           | problems.
        
             | reikonomusha wrote:
             | Common Lisp has Coalton, which implements a system above
             | H-M, close to Haskell's type system.
             | 
             | But that's beside the point; it's certainly false that H-M
             | is "table stakes" for languages, types or not. I don't even
             | think I need to go as far as listing countless examples
             | going against that claim.
        
             | KerrAvon wrote:
             | What languages in common use in 2022 support a Hindley-
             | Milner type system? This sounds a bit like pointless
             | academic gatekeeping...
        
         | cardanome wrote:
         | You might want to look into Coalton as statically typed,
         | functional language on top of Common Lisp:
         | https://github.com/coalton-lang/coalton
         | 
         | That said, Common Lisp while dynamically typed, is also
         | strongly typed. Many type errors are prevented at runtime. Also
         | you can declare types and have some limited form of static type
         | checking in SBCL.
        
         | agumonkey wrote:
         | There was a thread about Franz Lisp founder where he explains
         | that DARPA D.A.R.T project was done in C, about 30M LoC, and
         | failed hard, while the Lisp implementation was running nicely,
         | easy to fix in hours not days.
         | 
         | I'm not an experienced lisper, but it's not the first time I
         | read this kind of report.
        
         | reikonomusha wrote:
         | I have been using Common Lisp professionally for over a decade.
         | Largest codebase was probably ~100k lines for an embedded
         | optical fingerprint analysis and booking system for US law
         | enforcement agencies. The largest Lisp team I've worked on was
         | about 30 people for satcom hardware.
         | 
         | Every time I've described to people on the internet what makes
         | Lisp nice, I've been met with a riposte that such aspects
         | aren't unique to Lisp--be them interactive/incremental
         | development, macros, efficient machine code, editor
         | integration, whatever--or that a laundry list of features means
         | nothing and instead Lisp's value should somehow be proven
         | through its (hitherto comparatively dismal) popularity with
         | employers and software engineers. I myself have definitely
         | given up on an academic approach to proselytizing the language,
         | and instead have just focused my energy in building
         | applications and libraries people (especially employers) find
         | useful, at smaller cost and shorter time than other people are
         | able to provide.
         | 
         | It's like classical music. I can't convince you such music is
         | incredibly rich and pleasant, especially not by talking about
         | the harmonic theory of common practice. Instead, you just have
         | to listen and agree or disagree, I think.
         | 
         | And Lisp certainly has no secrets; it's old as can be and
         | extraordinarily and thoroughly documented. Countless people
         | (myself included) have spilled ink on the (alleged) virtues of
         | Lisp. It's all out there.
         | 
         | When it comes down to it, it's an incredibly flexible language
         | useful for prototyping and rapid development, while at the same
         | time supporting everything you need to transform your
         | application into a rock solid, robust, static binary. All of
         | Lisp's features balance in such a way that developer time and
         | energy are prioritized and consequently optimized.
         | 
         | P.S., Like a sibling comment mentioned, you can have Haskell-
         | level static typing in Common Lisp with Coalton:
         | https://github.com/coalton-lang/coalton
        
           | someguy101010 wrote:
           | how do you go about producing static binaries for sbcl?
        
             | reikonomusha wrote:
             | Load your application up in SBCL and call `save-lisp-and-
             | die` with the options you want (like what the `main`
             | function should be).
        
         | andi999 wrote:
         | I havent. But my hunch is it works best for rapid prototyping
         | with small teams.
        
       ___________________________________________________________________
       (page generated 2022-04-16 23:00 UTC)